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

如果你的生态系统包含在一个宏域中工作的数百个服务，你将不得不处理数以千计的服务通信方式。为了简化数据流，你应该考虑在某些事件发生时将消息分发到大量收件人的能力，而不管事件的上下文如何。换句话说，你需要一个事件总线来发布基于标准协议的事件并订阅它们。

对于事件总线，你可以使用任何能够操作所谓代理的系统： RabbitMQ 、 Kafka 、 ActiveMQ 和其它类似的系统。一般来说，数据的高可用性和一致性对于微服务至关重要，但是由于 CAP 定理 ，你仍然需要牺牲一些东西来实现总线的正确分布和集群管理。

很自然，事件总线应该能够解决各种服务间通信的问题，但是随着服务数量从成百上千增加到数万，即使是最好的基于事件总线的架构也可能会失败，因此你需要寻找另一种解决方案。一个很好的例子是集成总线方法，它可以扩展上述 “愚蠢的管道 —智能的消费者”(Dumb pipe — Smart consumer)策略的能力。

有很多原因决定了需要使用“ 企业集成/服务总线 ”方法，该方法旨在降低面向服务架构的复杂性。下面列出了部分原因：

• 多个消息的聚合
• 将一个事件拆分成几个事件
• 系统对事件响应的同步/事务分析
• 接口的适配，这对与外部系统的集成尤其重要
• 事件路由的高级逻辑
• 与相同服务的多重集成(从外部和内部)
• 数据总线的不可扩展集中化

作为企业集成总线的开源软件，你可能需要考虑 Apache ServiceMix ，它包含了设计和开发这种 SOA 所必需的几个组件。

数据库和其他有状态服务

和 Kubernetes 一样，对于需要数据持久性和与磁盘紧密合作的服务，Docker 彻底改变了游戏规则。有人说，服务应该在物理服务器或虚拟机上以旧的方式“生存”。我尊重这一观点，我不会就其利弊展开争论，但我相当肯定，这种说法的存在只是因为在 Docker 环境中暂时缺乏管理有状态服务的知识、解决方案和经验。

我还应该提到，数据库通常占据存储世界的中心位置，因此你选择的解决方案应该为在 Kubernetes 环境中工作做好充分准备。

根据我的经验和市场情况，我可以区分以下几组有状态服务，并为每一组服务提供最合适的面向 Docker 的解决方案示例：

• 数据库管理系统 — PostDock 是任何 Docker 环境中 PostgreSQL 的简单可靠的解决方案
• 队列/消息 代理(broker) — RabbitMQ 是构建消息队列系统和路由消息的经典软件。RabbitMQ 配置中的 cluster_formation 参数对于集群设置是必不可少的
• 缓存服务 — redis 被认为是最可靠和灵活的数据缓存解决方案之一
• 全文搜索 — 我前面已经提到过的 Elasticsearch 技术栈，最初用于文本搜索，但同样擅长存储日志和处理大量文本数据的任何工作
• 文件存储服务 — 为任何类型的文件存储和交付(ftp、sftp 等)提供的通用服务

镜像依赖

如果你还没有遇到你需要的包或依赖项已经从公共服务器上删除或暂时不可用的情况，请不要认为这种情况永远不会发生。为了避免任何不必要的不可用性并为内部系统提供安全性，请确保你的服务的构建和交付都不需要互联网连接。在内部网络中配置所有镜像和拷贝：Docker 镜像、rpm 包、源代码库、python/go/js/php 模块。

这些和任何其它类型的依赖都有自己的解决方案。最常见的方法可以通过在搜索引擎查询“ X 的私有依赖镜像 ”找到。

三、从架构回归现实

不管你喜不喜欢，你的整个架构迟早都会失败。这样的情况一直在发生：技术很快就过时了(1-5 年)，方法论变化慢一点(5-10 年)，设计原则和基础理论偶尔变化(10-20 年)，但不管怎么样这个趋势是不可阻挡的。

考虑到技术的过时，请始终努力将你的生态系统保持在技术创新的巅峰，规划和推出新的服务来满足开发人员、业务部门和最终用户的需求，向利益相关方推广新的实用程序，提供知识来推动你的团队和公司向前发展。

通过融入专业社区、阅读相关文献和与同事交流，可以让你保持领先地位。意识到你的机会，并在项目中正确使用新趋势。试验并应用科学的方法来分析你的研究结果，或者依靠你信任和尊重的其他人的结论。

（编辑：晋中站长网）

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