神话还是现实？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 等)提供的通用服务

镜像依赖

（编辑：西安站长网）

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