神话还是现实？Docker 和 Kubernetes 架构

如果你有一个统一的测试方法对 Docker 镜像(或“黑盒”)进行测试，你就可以假设这样的测试结果将允许你无缝地(并且问心无愧地)将 特性分支(feature-branch)集成到 git 存储库的 上游(upstream)或 主分支(master)中。

或许，这里唯一的障碍是集成和交付的顺序。当没有发布时，你如何在一个拥有一组并行 功能分支(feature-branches)的系统上防止“竞争条件”的发生?

因此，只有在没有竞争的情况下，这个过程才应该开始，否则“竞争条件”会一直萦绕在你的脑海中：

1. 尝试将 功能分支(feature-branch)更新到 上游分支(upstream)(git rebase/git merge)
2. 使用 Dockerfile 构建镜像
3. 测试所有构建好的镜像
4. 启动并等待，直到使用第 2 步中构建的镜像的系统成功完成部署
5. 如果前一步失败，将生态系统回滚到之前的状态
6. 将 功能分支(feature-branch)合并进 上游分支(upstream)，并将其提交到代码库

任何步骤中发生的任何失败都应该终止交付过程，并将任务返回给开发人员来修复错误，不管是测试失败还是代码合并冲突。

你可以使用此流程来在多个代码库上工作。只需一次对所有代码库执行每个步骤(在 A 库和 B 库上执行步骤 1，在 A 库和 B 库上执行步骤 2，如此类推)，而不是在每个单独的代码库上重复执行整个过程(在 A 库上执行步骤 1-6，在 B 库上执行步骤 1-6，如此类推)。

此外，Kubernetes 还允许你进行部分更新，以便执行各种 A/B 测试和风险分析。Kubernetes 在内部通过分离服务(访问点)和应用程序来实现这一点。你总是可以按期望的比例平衡组件的新版本和旧版本，以便于问题分析并为潜在的回滚提供可能。

回滚系统

架构框架的强制性要求之一是回滚任何部署过程的能力。这反过来又会带来一些显而易见和隐含的细微差别。以下是其中一些最重要的：

• 服务应该能够设置其环境以及回滚更改。例如，数据库迁移、RabbitMQ 的 schema 等等。
• 如果无法回滚环境，那么服务应该是 多态的(polymorphic)，并且支持旧版本和新版本的代码同时共存部署。例如：数据库迁移不应该导致旧版本服务的中断(通常是之前的 2 到 3 个旧版本)。
• 任何服务更新的向后兼容性。通常，这是应用编程接口 API 的兼容性、消息格式等等。

在 Kubernes 集群中的回滚状态非常简单(运行 kubectl rollout undo deployment/some-deployment，Kubernes 将恢复到以前的“快照”)，但是为了有效地做到这一点，你的元项目应该包含关于该快照的信息。非常不鼓励使用更复杂的交付回滚算法，尽管它们有时是必要的。

以下是触发回滚机制的因素：

• 发布后应用程序发生错误的百分比很高
• 来自关键监控点的信号
• 冒烟测试 (smoke tests)失败
• 手工模式— 人为因素

确保信息安全和审计

没有一个工作流可以神奇地“构建”防弹车级别的安全并保护你的生态系统免受外部和内部威胁，因此你需要确保你的架构框架在执行时着眼于公司在每个级别和所有子系统中的标准和安全策略。

稍后，我将在关于监控和告警的章节中讨论建议的所有三个级别解决方案，它们对系统完整性也至关重要。

Kubernetes 有一套良好的内置 访问控制机制 、 网络策略 、 事件审计 和其它与信息安全相关的强大工具，可用于构建出色的 周界保护(perimeter of protection)、抵御和防止攻击以及数据泄漏。

二、从开发工作流到架构

应该认真对待在开发流程和生态系统之间建立紧密集成的尝试。将这种集成的需求添加到传统架构需求集(灵活性、可伸缩性、可用性、可靠性、防威胁等)中，可以极大地增加架构框架的价值。这是非常关键的一个方面，它导致了DevOps(Development Operation)这个概念的出现。DevOps 是实现基础设施完全自动化和优化的一个合乎逻辑的步骤。然而，一个设计良好的架构架构和可靠的子系统，可以让 DevOps 任务最小化。

微服务架构

没有必要赘述面向服务的架构(SOA)的好处，包括为什么服务应该是 “微”(micro)粒度的。我只想说，如果你已经决定使用 Docker 和 Kubernetes，那么你很可能会理解(并接受)这样的观点：维护一个 单体(monolithic)架构是困难的，甚至在意识形态上是错误的。Docker 被设计成运行 单进程(single process)应用，并和持久层一起工作。它迫使我们在 DDD( 领域驱动开发(Domain-Driven Development))框架内思考。在 Docker 中，被打包的代码被视为一个暴露部分访问端口的黑盒。

生态系统的关键组成部分和解决方案

根据我设计可用性和可靠性更高的系统的经验，有几个组件对微服务的运行至关重要。稍后我将列出并讨论这些组件，即使以下我只是在 Kubernetes 环境中引用它们，你也可以将我的这个列表作为任何其他平台的检查表使用。

如果你(和我一样)能得出这样的结论，也即将这些组件作为一个常规 Kubernetes 服务来管理是非常好的，那么我建议你在不同于 “生产集群”(production)的单独集群中运行它们。例如， “预生产/准生产”(staging)集群可以在生产环境不稳定时挽救你的生命，因为这种情况下你会迫切需要一个能提供镜像、代码或监控工具的环境。可以说，这解决了鸡和蛋的问题。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!