“尬聊”服务基础平台架构规划

随着企业IT应用架构的演进，应用间服务交互的需求不断增大，可以说进化到微服务架构时达到鼎盛。而由此也带了应用间服务通信的相关问题，例如服务粒度是否匹配、交互是否友好、安全是否保障、应用重构对服务的影响等。

应用架构演进

另一方面，传统企业在IT规模不断扩大与进化的过程中，往往也存在多种应用架构并存的情况。在这种现状下，如何规划企业IT架构中面向服务的基础平台，以支撑应用架构的转型升级，这是笔者一直在思考的问题。

笔者结合自身的经验和理解，将所思记录下来，欢迎有志同道合者参与讨论与指正。

服务交互场景

目前企业内的服务交互场景大体可以分为三类：

• 内网应用间服务交互
• 内部外网应用与内网应用间的服务交互
• 内部应用与外部合作伙伴应用间的服务交互。

我们来看一下在不同的应用场景中服务交互各有什么特点。

内网应用间服务交互

通信方面需要解决最基本的两个问题：服务发现与适配转换。
首先，服务使用方需要知道所调用的服务在哪里，才能建立连接进行数据交换，这个过程需要服务发现；其次，如果应用双方采用了不同的通讯协议或报文格式（新建系统一般会采用新的技术栈，它和存量系统之间很可能存在这类需求），则还涉及到协议适配或报文转换的处理，相当于在应用之间有一个翻译，让双方能听得懂对方在说什么。
更复杂的情况，比如应用间交互可能还涉及到码表转换、服务组合甚至是业务逻辑处理，这些根据具体情况，可考虑由独立的中介平台、服务组合平台或者应用自身来承担相应的职责，这里就暂不多做讨论。

内部外网应用与内网应用间的服务交互

这个场景同样需要服务发现，并也可能存在适配转换的需求。但由于涉及到外网了，因此还多了一个关键的问题，那就是通信安全，包括服务使用者身份认证、服务访问权限控制、通信加密等

内部应用与外部合作伙伴应用间的服务交互

这个场景下的需求同样少不了服务发现、适配转换以及更高要求的通信安全。在实际应用中还可细分为两类场景，一类是内部服务能力开放给外部合作伙伴来访问，另一类是将外部合作伙伴的能力聚合进来供给内部应用访问。这就涉及到是遵循企业自身的技术标准，还是遵循外部合作伙伴技术标准的问题，进一步决定了是否需要支持定制化开发。

解决方案

首先我们来看看内网应用间的服务交互

在传统SOA架构下，应用间的服务交互通常基于企业服务总线（ESB）来承载。通过在ESB上配置服务信息来满足服务发现的需求，并且ESB产品天然就具备优秀的适配转换能力。在这种架构下，ESB形成了中心流量，然后通过对这个中心流量的管控来实现服务治理。
在微服务架构下，应用间的服务交互将更加频繁。ESB中心流量的实现方式将使原本已被拉伸服务链路的长度再翻一倍，增加链路耗时的同时也增大了中心瓶颈的风险。因此，这种场景下我们需要的是一个去中心化的分布式架构解决方案，我们将其称之为分布式服务架构。
一个完整的分布式服务架构提供的能力应包括服务注册发现、服务通信框架（RPC or RESTful）、服务治理及监控告警。

• 服务注册发现
  由于微服务架构带来了更大规模的节点部署，在以Docker为代表的云化平台的推动下，应用部署规模还会加速增长，这时靠人工进行服务信息的登记注册是不现实的，因此统一服务注册模型，实现注册发现的自动化是必须的，同时需要配备相应的服务注册发现中心，支持主动健康检查。常用的实现有ZK、Consul、etcd、eureka等开源框架。

此处提到的服务注册发现是针对一套微服务架构的，对于多套微服务架构并存时，我们是选择共用一个还是部署多个服务注册中心的问题，将在后续的文章中来讨论，此处就不展开讲了。

• 服务通信框架
  首先，支持对接服务注册发现中心，实现服务的自动注册发现；其次，提供通信控制能力，包括负载均衡、超时控制、熔断保护、流量控制、重试、认证授权与鉴权、动态请求路由、协议转换、对接监控等；所有的这些需要基于统一一个服务配置中心来管控。目前常用的开源解决方案有Spring Cloud全家桶、Dubbo+ZK。

• 服务治理
  服务治理主要包含四个方面的内容：
  * 服务交付：包括服务的规划、粒度的拆分、交付的方式，确保服务的一致性
  * 标准规范：明确如何定义服务及相关要求等
  * 变更管理：包括服务的版本控制、灰度升级等，确保服务升级不影响已有的服务使用者
  * 质量保证：明确服务SLA，并基于服务通信框架对运行态加以控制以保证SLA达成。

• 监控告警
  支持服务流水日志查询、分布式调用链追踪。实现方式需为非侵入式的，不影响服务运行。目前常用的开源解决方案有PinPoint、Zipkin等。

在服务通信框架的实现上，还有一种解决方案是新晋的服务网格（Service Mesh），通过将服务通信从应用系统中拆分出来，以非侵入式的方式下移为基础设施层。这一层处理应用系统间所有的通信问题，全面覆盖服务治理，让应用系统更关注业务本身。Service Mesh相比Spring Cloud全家桶等开源解决方案所具备的优势，一个是其非侵入性方便对存量系统进行的微服务改造，另一点是对跨语言的支持，这对各种遗留系统或外购系统来说是一大福音。

Service Mesh

不过，无论对于哪种分布式架构解决方案，核心的关键都在于服务注册发现，即需要有 统一的服务注册模型。只有先让服务使用者能够找到服务所在，我们才能考虑其他问题了。
另外需要进一步考虑的是，分布式架构解决方案目前讨论的是应用于一套微服务架构；当它需要与微服务架构之外的应用进行服务交互时，把它当做一个黑盒子来看，则又回到了传统SOA架构间服务交互的问题了。

接下来我们来讨论内部外网应用与内网应用间的服务交互

之前有提到，这个场景下的关键之一是安全控制，此外对于外网应用来说还需要一个访问入口。
一种实现方式是在外网和内网之间的DMZ区搭一个代理，将外部请求转发进来，然后由应用来处理其他认证鉴权等安全控制。
但毕竟安全控制和业务之间并没有紧耦合性，让每个涉及到外网应用的系统都实现一遍也是重复劳动。因此现在更常用的解决方案是通过DMZ区的代理来承载所需的安全控制，这种实现的理念和服务网格一样，同样是将与业务无关的通信问题剥离出来，这样实现的代理我们称之为API网关。
API网关的实现总的来说可以有三种选择：

• 一种是基于Netflix Zuul、Kong等开源组件，像Spring Cloud全家桶就推荐的Zuul；
• 二是自主开发；
• 三是如果应用部署在公有云的话，还可以考虑公有云服务商提供的配套API网关组件。

无论选择哪种方案，都需要满足高性能、高可用的基本要求，并且根据实际情况具备所需的可扩展、可维护能力。

最后看看内部应用与外部合作伙伴应用间的服务交互

从外网访问进来同样需要一个API网关的入口，但这个入口和内部外网应用的入口会是同一个吗？
我们对比两种场景的区别，首先区别会体现在服务目录就不一样，不同的业务需要或业管要求使得开放的能力范围并不一样；同时面向合作伙伴的网关重点在于开放，营造API生态；而面向内部外网应用的网关偏重于建立通道，保障安全。二是管理流程上可能会不一样，毕竟一个是内部一个是外部；三是前面提到的技术标准不一样。
因此，当存在以上任何一点不同，这个入口都不能复用。我们把面向内部外网应用的网关称之为内部网关，把面向外网合作伙伴的网关称之为开放平台网关。两者具体到落地的话，可能是同一套功能齐全的网关有不同的部署，也可能是不同的实现和部署。
一套实现一套部署行不行？关键在于数据隔离做不做到位、流程上是否可以区分开来、为区分流程是否又会增加接入门槛。考虑到这些，想来即使实现了也会非常重吧。“重”就会对运维运营带来更大复杂性和挑战。
另外还有对于需要引入的外部能力，通常需要遵循对方技术标准，这可能就会带来更多的定制化需求了。

ESB与API网关

在进一步总结之前，还有一个问题需要拿出来讨论：传统ESB和API网关在功能上有一定的重合，例如服务登记注册、路由转发、流控监控、安全控制等，那两者之间有什么区别呢？
对于这个问题，我们不能单看功能上的差异，而需要认识到它们定位上的不同。ESB是一种架构模式，主要面向服务以支持异构环境之间的互操作性，因此它面向的问题域集中在互操作性上，专注于各类适配需求与定制化对接的实现。API网关面向的问题域是服务开放，专注于服务开放过程中的各种安全、集成等问题；由于面向的问题域不一样，API网关在定位上可能并不会太偏重于异构环境的互操作性问题，而通常以标准的方式对外服务交付。受定位不同的影响，ESB和API网关在功能实现上就会有相应的取舍。
在实际应用过程中，对接的应用往往会需要感知ESB的存在，并按照与ESB约定的对接方式来进行交互；而API网关通常是透明的，外部用户不需要感知它的存在，它只是从各个服务提供者拆分出来的一层，集中在一起作为一个统一入口。
相对来说，ESB的能力会大于API网关所需的能力（因为其在连通性的支持上更强，但安全性的实现选择上可能不及API网关）。大家有时会问ESB和API网关之间是否可以相互替代？前面提到了，两者的定位不同，在架构上并不是可替代的关系，这个问题的根本其实是想问“ESB和API网关是否可以用相同的技术栈来实现”。这个问题就具体看相应的产品能力了，前面提到实施API网关的三种选择，开源方案和公有云组件并不适用于ESB的场景需求，于是只有在自主开发的这条路上，考虑是否有ESB产品能够支持API网关的场景需求了。

最终的形态

我们总结一下以上提到的各类场景及其对应的解决方案，内部之间、内外之间，分别涉及到ESB、分布式服务架构、API网关。其中ESB处理内部传统SOA架构中的服务交互，分布式服务架构处理内部微服务架构或分布式业务领域中的服务交互，API网关处理内外之间的服务交互，同时面向内部外网应用以及面向外部合作伙伴的API网关会有相对独立的部署，我们分别叫内部网关和开放平台网关。
如果把整个服务范围画成一个圆，圆的核心是承载整个服务体系运作的服务基础平台架构，那么这个服务基础平台架构应该是如下图这样了：

服务基础平台架构

TBD

1. 外部服务能力如何引入？对接外网的通道是API网关，但ESB是解决异构系统间互通性的能手，两个平台该如何选择？
2. 分布式服务架构是否可以扩展至传统SOA架构领域？
3. 一个服务中心 or 多个服务中心？
   4.应用间的异步交互？
   以上问题的核心更多在于服务注册模型是否统一，其他问题待逐步收集讨论