本文讲的是微服务架构强化的实时通信【编者的话】本文探讨了微服务架构模式是如何强化实时通信的，比如数据同步、动态RPC、发布/订阅消息传递、许可信息等以及相关的框架。
一个强大的后端支撑可以产生更加动态、可扩展和易于管理的部署策略，它可以用于实时通信和协作。
前不久，这篇文章已经开始了一个关于微服务的盛大宣言：化整为零！分而治之！“......企业IT架构师知道该怎么做。尽管如今几乎没有必要了。事实上，大多数企业架构以低耦合、高内聚节点集群的模式来构建后端都是可能的。
但是这种灵活性是有代价的：企业级微服务架构很快变得高度复杂。负载均衡集群，到端点的路由请求，分布式消息编排，分片存储层以及设备并发读写访问等等都还只是其中的一部分挑战。
随着从请求-响应工作流到实时数据流的不断增长 -- 无论是金融价格分发，社交消息，协作应用还是物联网（IoT）数据聚合--我们都必须重新考虑我们的服务交互方式和资源共享。如果你负责实施和支持实时通信和协作，加强后端的支撑将有助于你创建更动态，可扩展和易于管理的部署策略。
传统微服务架构
解决方案需求概述
我们的核心挑战是降低复杂性并增强可扩展性。有一个解决方案可以同时解决这两个问题：一个强劲的骨干网，用于统一资源访问和权限并改善路由和内部服务通信。这还需要一系列关键的改变：
- 数据同步替代分离的数据存储和消息传递——传统上，消息传递和数据存储是分离的。更新写入存储层；节点通过发布-订阅机制接收更新通知，然后使用自己的数据库连接查询新状态。这种方式伴随而来的是每个节点的额外连接和每次更新的多个步骤开销，进而导致更高的复杂性和性能的下降。
这种做法正逐渐被一种“数据同步”概念替代，诸如deepstream.io和RethinkDB的技术实现。数据同步将数据层建模为分布式状态。数据对象在微服务和客户端之间共享，并且可以被操纵和观察。对象的每个更改都会立即分发到所有连接的节点。
- 动态RPC替代静态路由表——在传统的REST架构中，远程过程调用（RPC）的可用端点是在路由器/负载均衡层静态配置的--许多企业级RPC框架，包括Apache Thrift 都是这种套路。这意味着更改或增加都必须同步多个配置并且通常需要重新启动/滚动更新。
高级消息队列协议（AMQP）代表如RabbitMQ或ZeroMQ，通过引入模式路由和动态交换创建带来巨大的改善。然而这些AMQP代理依然是让用户执行高级模式任务，如重新路由或基于度量的负载平衡。
新的RPC框架，如ZeroC's ICE或deepstream.io解决了这一问题。在这样的框架中，微服务在运行时可以动态分布式注册注册PRCs。传入的请求被路由到正确的端点并将响应返回给请求者。 智能负载平衡、重路由拒绝请求和其他额外功能使得这成为一个强大和少维护的方法。
- 服务间通信的发布/订阅消息传递——低耦合多对多通信的发布/订阅是一种可扩展和轻量级的内部消息传递模式。就像 Apache Kafka 的一个单独消息代理或像JBOSS Fuse企业事件总线一样。或者也可以融入统一平台的骨干网。
- 进入系统前的消息权限——在许多部署中，单独的微服务必须与Active Directory服务器或权限认证建立连接以确定给定的客户端是否可以执行特定操作。将消息权限移动到网关层，并确保消息不仅有效而且有权限，提高了安全性并且同时通过集中责任也降低了复杂性。这还有助于过滤掉恶意消息，在它们进入内部网络/虚拟私有云之前。
一个部署场景
向解决方案迈进
有不少的系统可以满足这些要求的方面，但真正的效果取决于他们结合的好不好。 RPC可用于预订系统的事务，并返回数据同步记录名称/流句柄以跟踪其状态。事件可用于在股票交易应用程序中快速广播指示价格更新，但最后通过数据同步提供最终价格。将所有这些功能从微服务和客户端连接到一个坚实、安全、可横向扩展的骨干网，能够显着降低复杂性，同时提高可扩展性和容错能力。
原文链接：Microservice Architecture Fortified for Real-Time Communications （翻译：朱高校）
===========================================
译者介绍
朱高校，H3C公司，目前从事OpenStack 、Docker相关研究工作。
原文发布时间为：2016-10-31
本文作者：朱高校
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：微服务架构强化的实时通信
