# 要解决的问题

如何降低服务接入成本

微服务架构下，不同服务之间的设计各不相同，服务之间的通信方式也不尽相同，随着业务规模的增长，外部服务会越来越多，如何降低服务的接入成本和管理好服务保证通信的稳定性就显得越发重要。

# 解决方案

通过合理的架构设计使用不同的工具来完成外部服务的接入和管理，减少同质工作，提升开发效率。

# 解决方案案例

# SDK

这是一种通过 SDK、Lib、Framework 等方式集成到应用服务自身中的解决方案。

这种方式简单并且使用广泛，但是因为和应用服务集成紧密，所以对业务是有侵入性，并且它还受限于应用服务自身的编程语言和技术限制。

同时它的升级需要随着应用服务的重新发布才能生效，如果使用方更新的不够积极，会使得服务提供方的服务升级难度变大，需要维护很多老旧接口。

如果公司的技术栈不够统一，需要服务提供方提供多种编程语言的版本，新增维护成本和同质工作。

# Sidecar

这是一种将服务对外进出通信全部收敛在一个 agent 中的解决方案，也叫边车模式。

这种方式是随着应用服务一起部署一个代理应用，它将服务治理的工作收敛起来：服务注册、服务发现、流量控制、链路追踪......因为 agent 是独立的应用，所以它可以独立的进行更新，并且对应用服务没有侵入性，不用受到应用服务的语言和技术的限制，很好的将服务治理细节和业务逻辑解耦，使得应用服务可以完全做到专注于业务逻辑。

因为对业务没有侵入性，所以这种模式也适用于老应用的服务改造，最小成本的完成服务架构升级。

# Service Mesh

Service Mesh 这个服务网络专注于处理服务和服务间的通讯，它的定位是负责构造一个稳定可靠的服务通讯的基础设施。

本质上是由 Sidecar 集群组成的，蓝色部分就是 Sidecar：

不同的是 Service Mesh 多了一个控制面板，于是这个集群就成了一个服务流量调度的平台：

由于 Service Mesh 定位是服务通讯的基础设施，可以将它理解成 7 层网络模型中的 TCP 协议层，包含了通信的大部分细节实现，并通过统一的控制面板来进行策略更新。

这样的架构下，理论上应用服务只需要关注好自己的业务逻辑，然后将应用部署到 Service Mesh 中即可，再也不用关心服务之间是如何通信的，以及通信中控制逻辑的细节处理，这个时候 Service Mesh 就像一个 PaaS 平台。

目前比较流行的 Service Mesh 开源软件是 Istio 和 Linkerd，还有一个 Conduit。

# Gateway

Gateway 是一个服务，也可以说是进入系统的唯一节点。

它跟面向对象设计模式中的 Facade 模式很像。Gateway 封装内部系统的架构，并且提供 API 给各个客户端。

它还可能有其他功能，属于可重可轻的一个服务：只包含通信相关的通用规则就和 Sidecar 一样，如果加上业务逻辑就比较重了，比如 API 灰度、聚合、编排等等业务属性。

其中 API 聚合，可以使用网关将多个单独请求聚合成一个请求，减少请求次数，提升整体的性能。API 编排则更有趣了，在微服务的架构下，要走完一个完整的业务流程，我们需要调用一系列 API，就像一种工作流一样，这个事完全可以通过网页来编排这个业务流程。我们可能通过一个 DSL 来定义和编排不同的 API，也可以通过像 AWS Lambda 服务那样的方式来串联不同的 API，这种场景下就是反哺应用服务使得应用服务表现形式更灵活。

Service Mesh 的架构和部署太过于复杂，会让我们运维层面上的复杂度变大，所以我们可以用一个只负责进入请求的 Gateway 来简化这个架构的复杂度。同时网关不必管理所有服务节点，而是可以根据需要，为指定的服务集群配上网关，也可以在网关前面加上更高层的网关，从而构造出一个星型的结构，但这样它会变成一个中心化的服务，在稳定性和性能上有更高的要求。