servicemesh去中心化
1. mesh组网原理
mesh组网原理是Mesh 客户端通过无线连接的方式接入到无线 Mesh 路由器，无线 Mesh 路由器以多跳互连的形式，形成相对稳定的转发网络。
在 WMN 的一般网络架构中，任意 Mesh 路由器都可以作为其他 Mesh 路由器的数据转发中继，并且部分 Mesh 路由器还具备因特网网关的附加能力。网关 Mesh 路由器则通过高速有线链路来转发 WMN 和因特网之间的业务。
WMN 的一般网络架构可以视为由两个平面组成，其中接入平面向 Mesh 客户端提供网络连接，而转发平面则在Mesh路由器之间转发中继业务。随着虚拟无线接口技术在 WMN 中使用的增加，使得WMN 分平面设计的网络架构变得越来越流行。
(1)servicemesh去中心化扩展阅读
Mesh网络的很多技术特点和优势来自于其Mesh网状连接和寻路，而路由转发的设计则直接决定Mesh网络对其网状连接的利用效率，影响网络的性能。在设计无线Mesh网络路由协议时要注意：
首先，不能仅根据“最小跳数”来进行路由选择，而要综合考虑多种性能度量指标，综合评估后进行路由选择；
其次，要提供网络容错性和健壮性支持，能够在无线链路失效时，迅速选择替代链路避免业务提供中断；
第三，要能够利用流量工程技术，在多条路径间进行负载均衡，尽量最大限度利用系统资源；
第四，要求能同时支持MP和Mesh STA。
常用的无线Mesh路由协议可参照Ad Hoc网络的路由协议，几种典型的路由协议包括：动态源路由协议（DSR）、目的序列距离矢量路由协议（DSDV）、临时按序路由算法（TORA）和Ad Hoc按需距离矢量路由协议（AODV）等。
2. Service Mesh 浅析：从概念、产品到实践
近几年，微服务架构逐渐发展成熟，从最初的星星之火到现在大规模的落地和实践，几乎已经成为分布式环境下的首选架构。然而软件开发没有银弹，基于微服务构建的应用系统在享受其优势的同时，痛点也越加明显。Service Mesh 技术也因此而生，受到越来越多的开发者关注，并拥有了大批拥趸。本文会从概念介绍开始，让大家理解 Service Mesh 技术出现的原因以及愿景；接着会对目前最主流的两个产品 Istio 和 AWS App Mesh 进行详细的比较；最后简要介绍一下我们目前在该领域的一些探索与实践。
Service Mesh - 服务通信的济世良方
Service Mesh 是什么？
Service Mesh（中文译做服务网格）这一概念由 Buoyant 公司的 CEO，William Morg」n 首先提出。2017 年 4 月该公司发布了第一个 Service Mesh 产品 Linkerd，这篇同一时间发表的文章 What’s a service mesh？ And why do I need one? 也被业界公认是 Service Mesh 的权威定义。
“A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”
其定义翻译为：Service Mesh 是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。这段话有点晦涩难懂，但只要抓住下面 4 个关键点就能轻松理解：
本质：基础设施层
功能：请求分发
部署形式：网络代理
特点：透明
如果用一句话来总结，我个人对它的定义是：Service Mesh 是一组用来处理服务间通讯的网络代理。
为什么需要 Service Mesh？
上面晦涩抽象的定义很难让你真正理解 Service Mesh 存在的意义。你可能会想，服务间通信（service-to-service communication）无非就是通过 RPC、HTTP 这些方式进行，有什么可处理的？没错，服务间只需要遵循这些标准协议进行交互就可以了，但是在微服务这样的分布式环境下，分散的服务势必带来交互的复杂性，而规模越大的系统其通信越加错综复杂。 分布式计算下的 8 个谬论 很好的归纳了分布式环境下存在的网络问题。而为了解决这些问题，提高系统的容错能力和可用性，出现了服务注册与发现、负载均衡、熔断、降级、限流等等和通信相关的功能，而这些才是 Service Mesh 要真正处理的问题。
Pattern：Service Mesh 这篇文章详细的讲述了微服务架构下通讯处理的演进，由此引出 Service Mesh 出现的意义和核心价值。下图为服务通信演变的过程：
最初，流量管理和控制能力（比如图例中的熔断、服务发现）是和业务逻辑耦合在一起，即便以引用包的方式被调用，依然解决不了异构系统无法重用的问题。
流控功能和业务耦合相当不美好，于是出现了提供这些功能的公共库和框架。但这些库通常比较复杂，无论是学习使用，与业务系统整合、维护都会带来很大的成本。
为避免花费太多时间开发和维护这些通用库，人们希望流量控制能力可以下沉到网络通讯栈的层面，但几乎无法实现。
于是另一种思路出现，就是将这些功能独立成一个代理，由它先接管业务服务的流量，处理完成后再转发给业务服务本身，这就是 Sidecar 模式。
为统一管理 Sidecar，该模式进一步进化，形成网络拓扑，增加了控制平面，演变成 Service Mesh（最后的网格图中，绿色代表业务服务，蓝色代表 sidecar 服务）。
可以说，Service Mesh 就是 Sidecar 的网络拓扑形态，Mesh 这个词也由此而来。（关于 Sidecar 模式这里不做讨论，你可以自行 Google）。
业务系统的核心价值应该是业务本身，而不是服务，微服务只是一种实现手段，实现业务才是目标。现有的微服务架构下，为解决可能出现的网络通信问题，提升系统的弹性，开发人员不得不花费大量时间和精力去实现流量控制相关的非业务需求，不能聚焦在业务本身。而 Service Mesh 的出现解决了这一问题，带来了下面 2 个变革：
解决了微服务框架中的服务流量管理的痛点，使开发人员专注于业务本身；
将服务通信及相关管控功能从业务程序中分离并下层到基础设施层，使其和业务系统完全解耦。
在云原生应用中，面对数百个服务或数千个实例，单个业务链路的请求经由服务的拓扑路径可能会非常复杂，单独处理非常必要。这就是 Service Mesh 的意义所在。
Service Mesh 的主要功能
那么 Service Mesh 到底能带来哪些实用的功能呢？可以把它们归纳为下面 4 个部分：
流量控制：流控是最主要也是最重要的功能，通过 Service Mesh，我们可以为应用提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各种控制能力；
-安全：在安全层面上，授权和身份认证也可以托管给 Service Mesh；
策略：可以为流量设置配额、黑白名单等策略；
可观察性：服务的可观察性一般是通过指标数据、日志、追踪三个方式展现的，目前的 Service Mesh 产品可以很容易和和主流的后端设施整合，提供给应用系统完整的监控能力。
通过上面的讲述，我相信 Service Mesh 的概念大家都已经有所了解。接下来我们来介绍两个重要的网格产品，让大家进一步了解 Service Mesh 的产品形态是什么样的。
Istio vs AWS App Mesh - 开源与闭环之争
目前市面上比较成熟的开源服务网格主要有下面几个：Linkerd，这是第一个出现在公众视野的服务网格产品，由 Twitter 的 finagle 库衍生而来，目前由 Buoyant 公司负责开发和维护；Envoy，Lyft 开发并且是第一个从 CNCF 孵化的服务网格产品，定位于通用的数据平面或者单独作为 Sidecar 代理使用；Istio，由 Google、IBM、Lyft 联合开发的所谓第二代服务网格产品，控制平面的加入使得服务网格产品的形态更加完整。
从今年的风向看，作为构建云原生应用的重要一环，Service Mesh 已经被各大云厂商认可，并看好它的发展前景。在 Istio 红透半边天的情况下，作为和 Google 在云服务市场竞争的 Amazon 来说，自然不愿错失这块巨大的蛋糕。他们在今年 4 月份发布了自己的服务网格产品：AWS App Mesh。这一部分内容我们会聚焦于 Istio 和 App Mesh 这两个产品，通过横向的对比分析让大家对 Service Mesh 的产品形态和两大云厂商的策略有一个更深入的认识。
产品定位
从官方的介绍来看，Istio 和 App Mesh 都明确的表示自己是一种服务网格产品。Istio 强调了自己在连接、安全、控制和可视化 4 个方面的能力；而 App Mesh 主要强调了一致的可见性和流量控制这两方面能力，当然也少不了强调作为云平台下的产品的好处：托管服务，无需自己维护。
从某种程度上讲，Istio 是一个相对重一点的解决方案，提供了不限于流量管理的各个方面的能力；而 App Mesh 是更加纯粹的服务于运行在 AWS 之上的应用并提供流控功能。笔者认为这和它目前的产品形态还不完善有关（后面会具体提到）。从与 AWS 技术支持团队的沟通中可以感觉到，App Mesh 应该是一盘很大的棋，目前只是初期阶段。
核心术语
和 AWS 里很多产品一样，App Mesh 也不是独创，而是基于 Envoy 开发的。AWS 这样的闭环生态必然要对其进行改进和整合。同时，也为了把它封装成一个对外的服务，提供适当的 API 接口，在 App Mesh 这个产品中提出了下面几个重要的技术术语，我们来一一介绍一下。
服务网格（Service mesh）：服务间网络流量的逻辑边界。这个概念比较好理解，就是为使用 App mesh 的服务圈一个虚拟的边界。
虚拟服务（Virtual services）：是真实服务的抽象。真实服务可以是部署于抽象节点的服务，也可以是间接的通过路由指向的服务。
虚拟节点（Virtual nodes）：虚拟节点是指向特殊工作组（task group）的逻辑指针。例如 AWS 的 ECS 服务，或者 Kubernetes 的 Deployment。可以简单的把它理解为是物理节点或逻辑节点的抽象。
Envoy：AWS 改造后的 Envoy（未来会合并到 Envoy 的官方版本），作为 App Mesh 里的数据平面，Sidecar 代理。
虚拟路由器（Virtual routers）：用来处理来自虚拟服务的流量。可以理解为它是一组路由规则的封装。
路由（Routes）：就是路由规则，用来根据这个规则分发请求。
上面的图展示了这几个概念的关系：当用户请求一个虚拟服务时，服务配置的路由器根据路由策略将请求指向对应的虚拟节点，这些节点最终会与集群中某个对外提供服务的 DNS 或者服务名一一对应。
那么这些 App Mesh 自创的术语是否能在 Istio 中找到相似甚至相同的对象呢？我归纳了下面的表格来做一个对比：
App MeshIstio
服务网格（Service mesh）Istio并未显示的定义这一概念，我们可以认为在一个集群中，由Istio管理的服务集合，它们组成的网络拓扑即是服务网格。
虚拟服务（Virtual services）Istio中也存在虚拟服务的概念。它的主要功能是定义路由规则，使请求可以根据这些规则被分发到对应的服务。从这一点来说，它和App Mesh的虚拟服务的概念基本上是一致的。
虚拟节点（Virtual nodes）Istio没有虚拟节点的概念，可以认为类似Kubernetes里的Deployment。
虚拟路由器（Virtual routers）Istio也没有虚拟路由器的概念。
路由（Routes）Istio中的目标规则（DestinationRule）和路由的概念类似，为路由设置一些策略。从配置层面讲，其中的子集（subset）和App Mesh路由里选择的目标即虚拟节点对应。但Istio的目标规则更加灵活，也支持更多的路由策略。
从上面的对比看出，App Mesh 目前基本上实现了最主要的流量控制（路由）的功能，但像超时重试、熔断、流量复制等高级一些的功能还没有提供，有待进一步完善。
架构
AWS App Mesh 是一个商业产品，目前还没有找到架构上的技术细节，不过我们依然可以从现有的、公开的文档或介绍中发现一些有用的信息。
从这张官网的结构图中可以看出，每个服务的橙色部分就是 Sidecar 代理：Envoy。而中间的 AWS App Mesh 其实就是控制平面，用来控制服务间的交互。那么这个控制平面具体的功能是什么呢？我们可以从今年的 AWS Summit 的一篇 PPT 中看到这样的字样：
控制平面用来把逻辑意图转换成代理配置，并进行分发。
熟悉 Istio 架构的朋友有没有觉得似曾相识？没错，这个控制平面的职责和 Pilot 基本一致。由此可见，不管什么产品的控制平面，也必须具备这些核心的功能。
那么在平台的支持方面呢？下面这张图展示了 App Mesh 可以被运行在如下的基础设施中，包括 EKS、ECS、EC2 等等。当然，这些都必须存在于 AWS 这个闭环生态中。
而 Istio 这方面就相对弱一些。尽管 Istio 宣称是支持多平台的，但目前来看和 Kubernetes 还是强依赖。不过它并不受限于单一的云平台，这一点有较大的优势。
Istio 的架构大家都比较熟悉，数据平面由 Envoy sidecar 代理组成，控制平面包括了 Pilot、Mixer、Citadel、Galley 等控件。它们的具体功能这里就不再赘述了，感兴趣的同学可以直接去 官网 查看详细信息。
功能与实现方式
部署
无论是 Istio 还是 App Mesh 都使用了控制平面+数据平面的模式，且 Sidecar 都使用了 Envoy 代理。Istio 的控制平面组件较多，功能也更复杂，1.0.x 版本完整安装后的 CRD 有 50 个左右。架构修改后 Mixer 的一些 adapter 被独立出去，crd 有所降低。下面是最新的 1.4 版本，安装后仍然有 24 个 crd。
而 App Mesh 就简单得多，只针对核心概念添加了如下 3 个 crd，用一个 controller 进行管理。
尽管 Istio 更多的 crd 在一定程度上代表了更加丰富的功能，但同时也为维护和 troubleshooting 增加了困难。
流量控制
尽管两者的数据平面都基于 Envoy，但它们提供的流量控制能力目前还是有比较大的差距的。在路由的设置方面，App Mesh 提供了相对比较丰富的匹配策略，基本能满足大部分使用场景。下面是 App Mesh 控制台里的路由配置截图，可以看出，除了基本的 URI 前缀、HTTP Method 和 Scheme 外，也支持请求头的匹配。
Istio 的匹配策略更加完善，除了上面提到的，还包括 HTTP Authority，端口匹配，请求参数匹配等，具体信息可以从官方文档的虚拟服务设置查看。下面两段 yaml 分别展示了两个产品在虚拟服务配置上的差异。
App Mesh 配置：
Istio 配置：
另外一个比较大的不同是，App Mesh 需要你对不同版本的服务分开定义（即定义成不同的虚拟服务），而 Istio 是通过目标规则 DestinationRule 里的子集 subsets 和路由配置做的关联。本质上它们没有太大区别。
除了路由功能外，App Mesh 就显得捉襟见肘了。就在笔者撰写本文时，AWS 刚刚添加了重试功能。而 Istio 借助于强大的 Envoy，提供了全面的流量控制能力，如超时重试、故障注入、熔断、流量镜像等。
安全
在安全方面，两者的实现方式具有较大区别。默认情况下，一个用户不能直接访问 App Mesh 的资源，需要通过 AWS 的 IAM 策略给用户授权。比如下面的配置是容许用户用任意行为去操作网格内的任意资源：
因此，App Mesh 的授权和认证都是基于 AWS 自身的 IAM 策略。
Istio 提供了两种认证方式，基于 mTLS 的传输认证，和 基于 JWT 的身份认证。而 Istio 的授权是通过 RBAC 实现的，可以提供基于命名空间、服务和 HTTP 方法级别的访问控制。这里就不具体展示了，大家可以通过官网 文档 来查看。
可观察性
一般来说，可以通过三种方式来观察你的应用：指标数据、分布式追踪、日志。Istio 在这三个方面都有比较完整的支持。指标方面，可以通过 Envoy 获取请求相关的数据，同时还提供了服务级别的指标，以及控制平面的指标来检测各个组件的运行情况。通过内置的 Prometheus 来收集指标，并使用 Grafana 展示出来。分布式追踪也支持各种主流的 OpenTracing 工具，如 Jaeger、Zipkin 等。访问日志一般都通过 ELK 去完成收集、分析和展示。另外，Istio 还拥有 Kiali 这样的可视化工具，给你提供整个网格以及微服务应用的拓扑视图。总体来说，Istio 在可观察方面的能力是非常强大的，这主要是因为 Mixer 组件的插件特性带来了巨大的灵活性。
App Mesh 在这方面做的也不错。从最新发布的 官方 repo 中，App Mesh 已经提供了集成主流监控工具的 helm chart，包括 Prometheus、Grafana、Jaeger 等。同时，AWS 又一次发挥了自己闭环生态的优势，提供了与自家的监控工具 CloudWatch、X-Ray 的整合。总的来说，App Mesh 在对服务的可观察性上也不落下风。
Amazon 与 Google 的棋局
AWS App Mesh 作为一个 2019 年 4 月份才发布的产品（GA），在功能的完整性上和 Istio 有差距也是情有可原的。从 App Mesh 的 Roadmap 可以看出，很多重要的功能，比如熔断已经在开发计划中。从笔者与 AWS 的支持团队了解的信息来看，他们相当重视这个产品，优先级很高，进度也比较快，之前还在预览阶段的重试功能在上个月也正式发布了。另外，App Mesh 是可以免费使用的，用户只需要对其中的实例资源付费即可，没有额外费用。对 AWS 来说，该产品的开发重点是和现有产品的整合，比如 Roadmap 列出的使用 AWS Gateway 作为 App Mesh 的 Ingress。借助着自己的生态优势，这种整合即方便快捷的完善了 App Mesh，同时又让生态内的产品结合的更紧密，使得闭环更加的牢固，不得不说是一步好棋。
和 App Mesh 目前只强调流控能力不同，Istio 更多的是把自己打造成一个更加完善的、全面的服务网格系统。架构优雅，功能强大，但性能上受到质疑。在产品的更迭上貌似也做的不尽如人意（不过近期接连发布了 1.3 到 1.4 版本，让我们对它的未来发展又有了期待）。Istio 的优势在于 3 大顶级技术公司加持的强大资源，加上开源社区的反哺，利用好的话容易形成可持续发展的局面，并成为下一个明星级产品。然而 Google 目前对 Istio 的态度有一些若即若离，一方面很早就在自家的云服务 gcloud 里提供了 Istio 的默认安装选项，但同时又发布了和 Istio 有竞争关系的 Traffic director 这个托管的控制平面。笔者的猜测是 Google 也意识到 Istio 的成熟不可能一蹴而就，鉴于网格技术托管需求的越发强烈，先提供一个轻量化的产品以占领市场。
目前各大厂商都意识到了网格技术的重要性并陆续推出了自己的产品（包括 AWS App Mesh，Kong 的 Kuma，国内的蚂蚁金服、腾讯云等），竞争也会逐渐激烈。未来是三分天下还是一统山河，让我们拭目以待。
我们的实践 - 从 Service Mesh 迈向云原生
最后这部分给大家简要介绍一下我们（FreeWheel）在 Service Mesh 领域的实践。希望通过一些前瞻性的探索，总结出最佳实践，为我们将来的微服务应用全面拥抱云原生提供一定的经验和指导。目前我们已经开发完成的 Data service 项目就整合了 AWS App Mesh，即将上线，并使用网格的能力进行智能路由和发布。
Data service 项目只包含两个服务：Forecast service 和 Query service，前者作为业务服务通过 Query service 查询来自持久层（ClickHouse）的数据；后者作为数据访问代理，从持久层获取数据并进行对象化的封装。这个 mini 的微服务系统非常适合作为一个先行者为我们探索网格的功能、性能、易用性等方面的能力，且范围足够小，不会影响到其他业务系统。
选择 AWS App Mesh 作为该项目的网格产品主要原因如下：
FreeWheel 是一个重度使用 AWS 各项服务的公司，未来所有的服务也都会全部托管的 AWS 上。作为一个闭环生态，App Mesh 可以和现有服务无缝整合，提高易用性；
相比 Istio 这样还不太成熟的开源产品，我们可以得到 AWS 技术团队的全力支持；
数据平面基于成熟高效的 Envoy，控制平面不存在 Istio 中的性能问题；
完全免费
下图是该项目的部署视图。前端请求从我们的业务系统 UIF 发送到 Forecast service，它作为 App Mesh 的一个虚拟节点，调用 Data service 进行数据查询。Data service 作为数据平面，会注入 App Mesh 的 sidecar 代理。这两个服务组成了一个 Mesh 网格，并无缝整合在 AWS 的 EKS 中。
下图是网格内部的逻辑视图，展示了如何利用 App Mesh 进行智能路由。Forecast service 作为调用者被定义为虚拟节点，Data service 作为虚拟服务，挂载着虚拟路由，内部根据需要可以设定若干路由规则。用 App Mesh 实现一个金丝雀发布的过程非常简单：假设在 Data service 的新版本（V2）发布前，流量都被指向 V1 版本；此时我们在 App Mesh 里配置好一个新的路由规则，将 10%的流量指向新的 V2 版本；只需要将新的规则通过 kubectl apply -f new-rule.yaml 应用到集群中，金丝雀发布就可以完成，且无缝切换，对用户透明。
在后续的工作中，我们会先验证 App Mesh 的性能和可靠性，然后逐渐的将更多的流量控制（如超时重试、熔断等）功能添加进来，并总结出一整套可行的实施方案，供大家参考。也欢迎对 Service Mesh 感兴趣的同学加入到我们的团队中，一起学习，共同进步。
总结
解耦是软件开发中永恒的主题，开发人员对消除重复的偏执是推动软件、以及架构模式演进的主要动力。而 Service Mesh 的核心价值就是将服务通信功能从业务逻辑中解耦，并下沉为基础设施，由控制平面统一管理。有人将 Service Mesh、Kubernetes 和 Serverless 技术称为云原生应用开发的三驾马车。Kubernetes 是云应用实际意义上的操作系统；Service Mesh 将服务通信功能剥离，实现了与业务的解耦；Serverless 让你不用关心应用的服务器。这三项技术让我们有能力实现应用开发的终极目标，那就是：只关注业务本身。而它们，也会引领我们通向未来云原生应用的诗和远方。
3. 什么是无线Mesh网络
无线Mesh网络即”无线网格网络”,它是“多跳（multi-hop）”网络，是由ad hoc网络发展而来，是一个动态的可以不断扩展的网络架构，任意的两个设备均可以保持无线互联，呈现出明显的去中心化态势。
无线Mesh网络基于呈网状分布的众多无线接入点间的相互合作和协同，具有以下特点：
部署速度快，安装简单。无线Mesh网络中，除了少部分节点设备需要网线和AP连接外，绝大部分设备都只需要一根电源线，不需要和AP连接，所有数据都是无线传输的，降低了有线布局的难度，同时扩展灵活。
传输可靠性高。在无线Mesh网络中，由于其多跳网络的特性，一个节点可以连接至少两个其他的节点，当某一个节点堵塞或者无响应时，无线Mesh网络可以根据情况选择其他的节点进行数据转播。换句话来说，就是无线Mesh网络拥有至少一条备用路径，提升了数据传输的可靠性。
非视距传输。在无线Mesh网络中，每一个节点都相当于一个中继器，相当于扩大了数据覆盖的范围，能够为连接AP的节点视距之外的用户提供网络，大幅度提高了无线网络的应用领域和覆盖范围。
尽管无线Mesh联网技术有着广泛的应用前景，但也存在一些影响它广泛部署的问题：
通信延迟。既然在Mesh网络中数据通过中间节点进行多跳转发，每一跳至少都会带来一些延迟，随着无线Mesh网络规模的扩大，跳接越多，积累的总延迟就会越大。一些对通信延迟要求高的应用，如话音或流媒体应用等，可能面临无法接受的延迟过长的问题。
安全问题。与WLAN的单跳机制相比，无线Mesh网络的多跳机制决定了用户通信要经过更多的节点。而数据通信经过的节点越多，安全问题就越变得不容忽视。
网络容量。实际应用中，由于mesh网络存在转发，每次转发之后速率都会降低，因此需要限制每个网络中节点的数量，否则会影响业务质量，即实际mesh网络中节点数量并非无限制增加。
4. API网关从入门到放弃
假设你正在开发一个电商网站，那么这里会涉及到很多后端的微服务，比如会员、商品、推荐服务等等。
那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题:
更好的方式是采用API网关，实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。
通过引入API网关，客户端只需要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。
API 注册
业务方如何接入网关?一般来说有几种方式。
协议转换
内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对于用户来说其中很多都不是很友好，或者根本没法对外暴露，比如Dubbo服务，因此需要在网关层做一次协议转换，将用户的HTTP协议请求，在网关层转换成底层对应的协议，比如HTTP -> Dubbo, 但这里需要注意很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不够详细的话，问题会很难定位。
服务发现
网关作为流量的入口，负责请求的转发，但首先需要知道转发给谁，如何寻址，这里有几种方式:
服务调用
网关由于对接很多种不同的协议，因此可能需要实现很多种调用方式，比如HTTP、Dubbo等，基于性能原因，最好都采用异步的方式，而Http、Dubbo都是支持异步的，比如apache就提供了基于NIO实现的异步HTTP客户端。
因为网关会涉及到很多异步调用，比如拦截器、HTTP客户端、bbo、redis等，因此需要考虑下异步调用的方式，如果基于回调或者future的话，代码嵌套会很深，可读性很差，可以参考zuul和spring cloud gateway的方案，基于响应式进行改造。
优雅下线
性能
网关作为所有流量的入口，性能是重中之重，早期大部分网关都是基于同步阻塞模型构建的，比如Zuul 1.x。但这种同步的模型我们都知道，每个请求/连接都会占用一个线程，而线程在JVM中是一个很重的资源，比如Tomcat默认就是200个线程，如果网关隔离没有做好的话，当发生网络延迟、FullGC、第三方服务慢等情况造成上游服务延迟时，线程池很容易会被打满，造成新的请求被拒绝，但这个时候其实线程都阻塞在IO上，系统的资源被没有得到充分的利用。另外一点，容易受网络、磁盘IO等延迟影响。需要谨慎设置超时时间，如果设置不当，且服务隔离做的不是很完善的话，网关很容易被一个慢接口拖垮。
而异步化的方式则完全不同，通常情况下一个CPU核启动一个线程即可处理所有的请求、响应。一个请求的生命周期不再固定于一个线程，而是会分成不同的阶段交由不同的线程池处理，系统的资源能够得到更充分的利用。而且因为线程不再被某一个连接独占，一个连接所占用的系统资源也会低得多，只是一个文件描述符加上几个监听器等，而在阻塞模型中，每条连接都会独占一个线程，而线程是一个非常重的资源。对于上游服务的延迟情况，也能够得到很大的缓解，因为在阻塞模型中，慢请求会独占一个线程资源，而异步化之后，因为单条连接所占用的资源变的非常低，系统可以同时处理大量的请求。
如果是JVM平台，Zuul 2、Spring Cloud gateway等都是不错的异步网关选型，另外也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的异步支持进行自研。
缓存
对于一些幂等的get请求，可以在网关层面根据业务方指定的缓存头做一层缓存，存储到Redis等二级缓存中，这样一些重复的请求，可以在网关层直接处理，而不用打到业务线，降低业务方的压力，另外如果业务方节点挂掉，网关也能够返回自身的缓存。
限流
限流对于每个业务组件来说，可以说都是一个必须的组件，如果限流做不好的话，当请求量突增时，很容易导致业务方的服务挂掉，比如双11、双12等大促时，接口的请求量是平时的数倍，如果没有评估好容量，又没有做限流的话，很容易服务整个不可用，因此需要根据业务方接口的处理能力，做好限流策略，相信大家都见过淘宝、网络抢红包时的降级页面。
因此一定要在接入层做好限流策略，对于非核心接口可以直接将降级掉，保障核心服务的可用性，对于核心接口，需要根据压测时得到的接口容量，制定对应的限流策略。限流又分为几种:
稳定性
稳定性是网关非常重要的一环，监控、告警需要做的很完善才可以，比如接口调用量、响应时间、异常、错误码、成功率等相关的监控告警，还有线程池相关的一些，比如活跃线程数、队列积压等，还有些系统层面的，比如CPU、内存、FullGC这些基本的。
网关是所有服务的入口，对于网关的稳定性的要求相对于其他服务会更高，最好能够一直稳定的运行，尽量少重启，但当新增功能、或者加日志排查问题时，不可避免的需要重新发布，因此可以参考zuul的方式，将所有的核心功能都基于不同的拦截器实现，拦截器的代码采用Groovy编写，存储到数据库中，支持动态加载、编译、运行，这样在出了问题的时候能够第一时间定位并解决，并且如果网关需要开发新功能，只需要增加新的拦截器，并动态添加到网关即可，不需要重新发布。
熔断降级
熔断机制也是非常重要的一项。若某一个服务挂掉、接口响应严重超时等发生，则可能整个网关都被一个接口拖垮，因此需要增加熔断降级，当发生特定异常的时候，对接口降级由网关直接返回，可以基于Hystrix或者Resilience4j实现。
日志
由于所有的请求都是由网关处理的，因此日志也需要相对比较完善，比如接口的耗时、请求方式、请求IP、请求参数、响应参数(注意脱敏)等，另外由于可能涉及到很多微服务，因此需要提供一个统一的traceId方便关联所有的日志，可以将这个traceId置于响应头中，方便排查问题。
隔离
比如线程池、http连接池、redis等应用层面的隔离，另外也可以根据业务场景，将核心业务部署带单独的网关集群，与其他非核心业务隔离开。
网关管控平台
这块也是非常重要的一环，需要考虑好整个流程的用户体验，比如接入到网关的这个流程，能不能尽量简化、智能，比如如果是bbo接口，我们可以通过到git仓库中获取源码、解析对应的类、方法，从而实现自动填充，尽量帮用户减少操作；另外接口一般是从测试->预发->线上，如果每次都要填写一遍表单会非常麻烦，我们能不能自动把这个事情做掉，另外如果网关部署到了多个可用区、甚至不同的国家，那这个时候，我们还需要接口数据同步功能，不然用户需要到每个后台都操作一遍，非常麻烦。
这块个人的建议是直接参考阿里云、aws等提供的网关服务即可，功能非常全面。
其他
其他还有些需要考虑到的点，比如接口mock，文档生成、sdk代码生成、错误码统一、服务治理相关的等，这里就不累述了。
目前的网关还是中心化的架构，所有的请求都需要走一次网关，因此当大促或者流量突增时，网关可能会成为性能的瓶颈，而且当网关接入的大量接口的时候，做好流量评估也不是一项容易的工作，每次大促前都需要跟业务方一起针对接口做压测，评估出大致的容量，并对网关进行扩容，而且网关是所有流量的入口，所有的请求都是由网关处理，要想准确的评估出容量很复杂。可以参考目前比较流行的ServiceMesh，采用去中心化的方案，将网关的逻辑下沉到sidecar中，
sidecar和应用部署到同一个节点，并接管应用流入、流出的流量，这样大促时，只需要对相关的业务压测，并针对性扩容即可，另外升级也会更平滑，中心化的网关，即使灰度发布，但是理论上所有业务方的流量都会流入到新版本的网关，如果出了问题，会影响到所有的业务，但这种去中心化的方式，可以先针对非核心业务升级，观察一段时间没问题后，再全量推上线。另外ServiceMesh的方案，对于多语言支持也更友好。
5. mesh组网会因为某一方路由器性能的好坏影响wifi质量吗
对于家用 Mesh网络的看法。 Mesh网络构架示意图 如果要用一个词来概括 Mesh的优势,那就是“去中心化”。双频路由器的无线MESH组网，都会有衰减，因为要占用无线带宽进行组网，给终端的带宽就不足了，
建议改桥接（中继模式）
wifi统一，，如华为的AX3
或 /WS5200（双频（2.4GHz，5GHz）二百元）最高传输速率：1167Mbps
设置中继模式：华为WS5200路由器设置无线桥接(Wi-Fi中继)的方法。 无线桥接或者Wi-Fi中继,指的是让WS5200路由器,通过无线的方式,与另一个可以上网的路由器连接起来,
6. 基于ServiceMesh服务网格的去中心化微服务管控治理平台
首先说明下我最近在思考的一个产品规划，即基于ServiceMesh服务网格思路，参考开源的Istio等实现架构来搭建一个完整的微服务治理管控平台。
在前面文章里面我就提到了，在实施微服务架构后，由于微服务将传统的单体应用进行了拆分，颗粒度更细。因此整个集成的复杂度，后续的管控治理复杂度都急剧增加。
当前也出现了类似SpingCLoud主流的微服务开发框架，实现了服务注册和发现，安全，限流熔断，链路监控等各种能力。同时对于服务注册，限流，服务链监控等本身又出现了大量的开源组件，类似服务注册的Nacos，Consul，限流熔断的Sentinel，链接监控的SKyWalking等开源组件。
当我们在思考微服务开发框架和开源组件的时候你会发现。
在SpingCLoud外的各类开源组件本身和微服务开发过程是解耦的，也就是说这些开源组件更加方便地通过配置增加管控能力，或者通过下发一个SDK包或Agent代理组件来实现管控能力。以尽量减少对微服务开发过程的影响。
而对于SpingCLoud微服务框架，在使用中有一个最大的问题就是开发态和治理态的耦合，也就是说一个微服务模块在开发的时候，你会引入很多治理态的内容。类似限流熔断，类似链路监控等能力，都需要你在开发状态增加配置文件，或对接口实现类进行扩展等。
微服务开发本身应该是一个简单的事情。
其核心是实现业务功能和规则逻辑，并暴露轻量的Http Rest API接口实现和前端交互或者实现和其它微服务模块之间的横向交互协同。
也就是说如果不考虑管控治理层面的内容，你采用最小化的SpingBoot来进行微服务开发足够的，或者你仍然可以采用传统的Java架构进行微服务开发，只要确保最终暴露Http API接口即可。
但是如果要考虑治理的内容，你会发现会引入注册中心，限流熔断，安全，服务链监控一系列的管控治理组件，导致整个微服务开发过程，集成过程都复杂化。
因此构建微服务治理平台的初衷即：
在这里还是先简单梳理下业务需求和业务功能场景。
01 服务注册和服务发现
仍然需要实现最基本的当前微服务自注册，自发现能力。这个在开发阶段需要暴露的接口增加注解还是必须的。在ServiceMesh下，由于存在本地Sidecar代理，因此在本地代理和微服务一起容器化部署下去后，会扫描微服务中需要暴露的接口，并完成微服务和API接口服务的注册工作。 也就是传统的应用开发集成中，手工接口API接口服务注册和接入的过程没有了，这个过程应该彻底地自动化掉。
注意这里的注册不仅仅是到微服务粒度，而是可以到微服务API接口粒度。
因此我们需要实现在微服务部署和交付后，微服务注册和微服务中的API接口注册全部自动完成。在微服务集群扩展的时候，相关的注册信息和配置信息也自动更新和扩展。
一个微服务模块在部署和交付后。
进入到微服务治理平台就能够看到当前有哪些微服务已经注册，进入到单个微服务里面，就可以看到当前微服务究竟有哪些细粒度的API接口已经注册。
02 服务安全和双重管理
对于一个微服务暴露的API接口，可以看到部分API接口仅仅是提供给前端微服务使用，但是部分API接口是需要提供给其它横向的微服务模块使用。
一个是前端调用后端API接口，一个是后端各个微服务中心间接口交互。
在安全管理的时候实际需要对这两类API接口分别进行管理。如果仅仅是前端功能使用，那么类似JWT+Token的安全措施即可，同时对于的日志流量并不一定需要完全记录和入库。如果是横向微服务间调用，那么安全要求更高，需要支持Token，用户名密码，IP地址验证等多种安全管控要求。
对于前后端的使用，往往仅授权到微服务层级即可。但是对于横向微服务间调用，那么服务授权必须到API接口服务粒度， 能够针对单个微服务API接口独立授权和管理。
03 服务限流熔断
同样这个功能不应该在微服务开发阶段进行任何配置或代码文件的增加。
在微服务成功的部署和交付上线后，应该能够针对微服务，微服务API接口两个不同的颗粒度进行服务限流设置。当然需要支持类似并发量，时长，错误数，数据量等多种限流熔断策略。
比如一个微服务单点能够支撑的最大并发量是1000TPS，那么这就是最基本的限流条件。我只需要设置单点能量，而不是设置集群能力。管控治理平台要管理的是通过负载均衡分发后到单个节点的流量能够控制到1000TPS。如果你部署了5个微服务节点，那么实际能够支撑的最大流量就是5000TPS。
由于采用Mesh去中心化的架构模式，因此实际微服务间的调用数据流量并不会通过微服务治理平台，微服务治理平台本身并没有太大的性能负荷压力。这个是和传统的ESB或API网关不同的地方，即API网关的限流一方面是保护API网关本身，一个是保护下游的微服务模块。
04 接口调用日志记录
注意这个功能本身也是可以灵活配置的，可以配置单个微服务，也可以配置单个API接口服务是否记录日志，包括日志记录是只记录调用时间和状态，还是需要记录想的接口调用消息报文数据。
在去中心化架构模式下，接口调用日志记录相对来说很容易实现。
即通过Sidecar边车首先对消息和数据流量进行拦截，任何将拦截的数据统一推送到消息中间件，消息中间件再将日志信息存入到分布式文件存储或对象存储中。
对于接口调用日志本身应该区分日志头信息和消息日志信息，对于日志头调用记录信息应该还需要推送到类似ELK组件中，以方便进行关键日志的审计和问题排查。
05 服务链路跟踪和监控
注意，在传统的服务链跟踪中，需要在微服务端配置Agent代理。而采用Mesh化解决方案后，该部分代理能力也移动到了Sidecar边车代理中实现。
服务链路监控不仅仅是微服务和API接口间的调用链路，也包括融入常规APM应用性能监控的能力，能够实现前端界面操作后发起的整个应用链路监控。
应用链路监控一方面是进行日志和错误分析，一方面是进行性能问题排查和优化。
06 和DevOps和容器云的集成
简单来说就是开发人员只需要按照标准规范开发单个微服务模块，然后走DevOps持续集成和交付过程进行部署。
在和DevOps平台进行集成后，DevOps在进行自动化部署前会下发Sidecar代理边车，实现对微服务本身的流量拦截和各种管控治理能力。在整个过程中Sidecar对开发者不可见，满足最基本的服务透明要求。
在通过DevOps部署到容器云平台后，满足基于资源调度策略进行后续微服务集群资源的自动化动态扩展能力。同时微服务在扩展后自动进行相应的集群注册，微服务API接口注册等操作。
在传统的SpingCLoud开发框架中，本身注册中心包括了对微服务模块的心跳检查和节点状态监控能力。在和Kurbernetes集群集成和融合后，完全可以采用Kurbernetes集群本身的心跳监控能力。
简单总结
最后总结下，整个微服务治理平台基于ServiceMesh去中心化架构思路来定制，但是需要实现类似传统ESB总线或API网关的所有管控治理能力。
对于最终的使用者来说并不关心治理能力实现是否是去中心化架构，而更加关心两个点。第一个点是开发阶段不要引入治理要求，第二就是能够实现核心能力的集中化管控和可灵活配置扩展。
也就是你可能上层看到的是一个传统的SOA治理管控平台，但是底层却是采用了去中心化的ServiceMesh架构来实现微服务治理管控能力。
7. 无线mesh原理
无线Mesh网络即”无线网格网络”,它是“多跳（multi-hop）”网络，是由ad hoc网络发展而来，是一个动态的可以不断扩展的网络架构，任意的两个设备均可以保持无线互联，呈现出明显的去中心化态势。
无线Mesh网络基于呈网状分布的众多无线接入点间的相互合作和协同，具有以下特点：
部署速度快，安装简单。无线Mesh网络中，除了少部分节点设备需要网线和AP连接外，绝大部分设备都只需要一根电源线，不需要和AP连接，所有数据都是无线传输的，降低了有线布局的难度，同时扩展灵活。
传输可靠性高。在无线Mesh网络中，由于其多跳网络的特性，一个节点可以连接至少两个其他的节点，当某一个节点堵塞或者无响应时，无线Mesh网络可以根据情况选择其他的节点进行数据转播。换句话来说，就是无线Mesh网络拥有至少一条备用路径，提升了数据传输的可靠性。
非视距传输。在无线Mesh网络中，每一个节点都相当于一个中继器，相当于扩大了数据覆盖的范围，能够为连接AP的节点视距之外的用户提供网络，大幅度提高了无线网络的应用领域和覆盖范围。
尽管无线Mesh联网技术有着广泛的应用前景，但也存在一些影响它广泛部署的问题：
通信延迟。既然在Mesh网络中数据通过中间节点进行多跳转发，每一跳至少都会带来一些延迟，随着无线Mesh网络规模的扩大，跳接越多，积累的总延迟就会越大。一些对通信延迟要求高的应用，如话音或流媒体应用等，可能面临无法接受的延迟过长的问题。
安全问题。与WLAN的单跳机制相比，无线Mesh网络的多跳机制决定了用户通信要经过更多的节点。而数据通信经过的节点越多，安全问题就越变得不容忽视。
网络容量。实际应用中，由于mesh网络存在转发，每次转发之后速率都会降低，因此需要限制每个网络中节点的数量，否则会影响业务质量，即实际mesh网络中节点数量并非无限制增加。
8. Service Mesh概述
第一代微服务架构 Spring Cloud ，基于SDK/开发框架的微服务治理体系。
第二代微服务架构 Service Mesh（服务网格），基于透明代理的服务治理体系。
Service Mesh的优势：是微服务时代的通信层。Buoyant的CEO William Morgan，也就是Service Mesh这个词的发明人，对Service Mesh的定义：
服务网格是一个 基础设施层，用于处理服务间通信 。云原生应用有着复杂的服务拓扑，服务网格 保证请求在这些拓扑中可靠地穿梭 。在实际应用当中，服务网格通常是由一系列轻量级的 网络代理 (可以看成Nginx)组成的，它们与应用程序部署在一起，但 对应用程序透明 。
9. mesh组网原理
mesh组网原理：WMN由三类不同的无线网元组成：网关路由器（具有网关/网桥功能的路由器），Mesh路由器（接入点）和Mesh 客户端（移动端或其他）。
其中，Mesh 客户端通过无线连接的方式接入到无线 Mesh 路由器，无线 Mesh 路由器以多跳互连的形式，形成相对稳定的转发网络。
在 WMN 的一般网络架构中，任意 Mesh 路由器都可以作为其他 Mesh 路由器的数据转发中继，并且部分 Mesh 路由器还具备因特网网关的附加能力。网关 Mesh 路由器则通过高速有线链路来转发 WMN 和因特网之间的业务。
WMN 的一般网络架构可以视为由两个平面组成，其中接入平面向 Mesh 客户端提供网络连接，而转发平面则在Mesh路由器之间转发中继业务。随着虚拟无线接口技术在 WMN 中使用的增加，使得WMN 分平面设计的网络架构变得越来越流行。
10. 溯源微服务：企业分布式应用的一次回顾
微服务作为架构风格几乎成为云时代企业级应用的事实标准，构成微服务的技术元素本身却并非革命性。跨平台的分布式通信框架、地址无关的服务注册与发现、智能路由与编排等技术早已在CORBA、SOA时代实现了一遍又一遍，我们不禁好奇，微服务有什么不同？本文是对企业分布式应用的一次回顾，与前微服务时代相比，我们究竟在哪些领域吸取了教训，哪些方面持续搞砸。
架构的关键在于构造合理的封装抽象。良好的抽象构造如进程，由操作系统接管CPU调度、内存地址空间分配和I/O，程序员的心智从此解放，得以聚焦在业务逻辑上。糟糕的抽象往往引向万丈深渊，大量精力被浪费在抽象泄露带来的问题上。
让我们从组件间的通信开始，最初人们认为这只是需要被解决的技术要素。
关于如何实现跨平台的分布式通信，30年前诞生的CORBA架构在今天来看仍然非常漂亮：通过定义IDL/ORB/API我们可以将内存对象任意分布于网络中。只要共享IDL，对象可以由C++/Java等不同的语言实现，其互相调用就像本地方法一样简单。然而实践经验告诉我们，分布式系统总是会出现本地调用不会发生的各种问题：网络的开销、传输的延迟、消息的超时和丢包、远端系统的崩溃……物理世界的技术约束是无法被忽略的，我们没有办法把分布式调用抽象成简单的本地方法。因此Martin Fowler在他的< 企业应用架构模式>里提出了著名分布式对象第一定律：“不要分布式你的对象”。相反，你应该把尽可能多的操作置于进程之内，通过replicate整个应用的方式来实现系统的scale。
由分析师们发起的SOA运动从另一个角度看待这个问题，Web Service应该是对企业资产和业务能力的封装。我们开始站在更高的维度，远过程调用不再只是技术意义上的集成。WSDL不仅是通信调用的接口，更是服务间的契约；UDDI不仅是服务描述、发现、集成的中心，更是企业业务与服务的黄页。WS-*在厂商的裹挟下发展成包罗万象，却也没几个人能掌握。开发者们抱怨花了太多时间写冗余的XML制定所谓的规范，WSDL生成的客户端也将不同服务耦合在一起。是否有更加轻量敏捷的方式，让我们快点开始写第一行生产代码？
于是我们看到REST的兴起。起初是作为反叛，用更加轻量级的方式(http+json)使用Web。然后我们发现”企业级”应用并非需要ESB这样昂贵的专有中间件，由”消费级”技术组成的万维网是世界上最大规模的分布式网络，我们应该向其学习如何构建健壮、可演化的系统。Roy Fielding那篇论文所提出的无状态、可缓存等特征已经深入人心，而狭义上的REST API(基于资源的URI、HTTP动词和状态码的标准接口)也成为API设计的最佳实践。
既然API和网站一样都是基于通用Web技术，API是否可以像网站一样作为产品提供呢(APIs as proct)？于是越来越多的企业开始将自己的业务能力封装成API，提供给消费者，随之而来的是更弹性的商业应用和更灵活的计费方式。很多组织也着手构建自己的API市场，把内部IT能力整合、复用，并为孵化外部产品做准备。API已经成为商业价值主张的一部分。
我们从聚焦实现细节的rpc出发，来到了更具价值导向的REST API。即使构建内部系统，以消费者驱动的方式，也总是能帮助我们设计出更加松耦合和易于演进的API。
编程语言中的组件构造(如Java中的jar, C#中的dll)是软件架构师们封装可复用单元的最常用武器。组件作为理论上的最小部署单元，在工程实践中却并不容易独立变更。一般应用程序需要讲多个组件打包成一个部署单元(如war包)，链接在内存地址中进行调用。对单个组件的热更新往往对组件间耦合和对象状态管理有很高的要求，重新部署整个应用一般是默认选项。以进程为边界构建可独立部署的服务成为架构师的另一项选择。
早期的服务只是单纯的技术构件，大多数组织从纯粹的技术实现角度考虑服务的划分。SOA的推动者们指出企业的信息资产应该被复用，信息孤岛应该被打通。通过将不同的服务编排组合，我们应该能够实现IT对业务更加灵活的支撑。
SOA的服务建模一般采用业务流程驱动的方式。一个典型的SOA设计是由业务分析师自顶向下地对企业现有业务流程进行分析，通过BPM引擎对流程进行建模，向下分解成组合服务，并进一步拆分成数据访问服务(很多可怜的SOA实现中数据的访问被拆分成不同的读服务和写服务)。然而这带来的问题是，服务跟服务间的耦合非常严重。当我的业务发生了变化，可能会需要修改很多不同的服务，涉及到多个团队的沟通和协调。在运行时层面，服务器间的通信非常频繁，用户在界面上的一次点击按钮，对应的后台多层服务间的级联通信。这给系统性能和稳定性也带来了巨大的挑战。SOA式的服务建模从分析型思维出发，却往往低估了分布式系统和跨团队协调的复杂度，导致服务拆分粒度过细。
微服务的名字常常让人误解，但实施正确的微服务粒度可能并不”微”。Martin Fowler与James Lewis在开创微服务定义的一文中已经指出微服务应该围绕完整的业务能力。今天我们在做微服务设计时，常常利用领域驱动设计中的Bounded Context来进行服务边界的划分。假设你的库存管理是一个独立的业务子域，针对库存的维护和操作应该被放到通过一个上下文和微服务中，由一个团队进行开发维护。多数业务变更都发生在上下文内部，不涉及跨团队协调。单个codebase内的重构和部署让发布更加容易。维护库存所需要的信息查询的调用多发生在进程内，更好的性能，同时无需处理额外的一致性问题。
如今我们对服务的定义已经超越了技术组件，领先的组织已经在尝试将design thinking, business operating model应用到微服务设计中。
即使有了设计合理的服务于API，我们仍然需要与之匹配的工程实践才能将其顺利实施。
今天仍有很多企业使用集中式的应用服务器部署应用：开发团队将软件包构建出来，再统一安装到应用服务器中。对应用团队来说，这往往意味着漫长的反馈周期和痛苦的自动化。我们很早就推荐用Jetty这样内嵌式的应用容器部署软件，启动更快，测试环境更接近生产。one Tomcat per VM的部署方式虽然运行时开销较大，却是前容器时代隔离性最好的服务部署模式。Docker将这个实践更进一步，除了更轻量级的隔离，我们第一次可以将软件和所依赖的环境本身打包成版本化的artifact，彻底统一开发和生产环境。容器技术的成熟让我们可以将部署去中心化，开发团队可以独立部署一个服务。
数据库耦合是影响服务独立变更的另一重要因素。相比代码构成的应用软件，数据库schema更加难以变动。因为难以测试、难以兼顾性能优化和耦合的发布周期等因素，服务间以数据库集成成为臭名昭著的反模式。服务间的集成应该依赖封装好的显示接口，而不是数据库这种实现细节。我们应该在兼顾数据一致性的情况下，为每个微服务分配独立的db schema甚至db instance。如果说十年前数据几乎等同于关系数据库。如今数 据则可能呈现出各种形态：键值、文档、时间序列、图…我们完全可以采用更加合适的技术，以去中心化的方式进行微服务的数据治理。
即使将这一切都解耦，如果将交给一个集中的团队去实施，很有可能最终还是得到一个耦合的架构。这就是是著名的康威定律。康威定律告诉我们“设计系统的架构受制于产生这些设计的组织的沟通结构”。但同样我们可以将康威定律反转应用：如果你想达成一个目标架构，则必须对团队结构进行调整，使之和目标架构对齐。相比单体系统，微服务在运行时监控和运维所带来的挑战更大。”you build it, you run it”的DevOps文化成为必须。监控运维不再是Ops部门的事情，产品团队必须对微服务的整个生命周期负责。授权的去中心化自治团队是实施微服务的必要条件。
我们在很多方向的确取得了进展。但即使在微服务时代，很多问题仍然在轮回发生着，似乎我们总是无法吸取 历史 的教训。让我们看一看那些挥之不去的反模式阴云。
另一个挥之不去的阴影是ESB。ESB在将异构的应用wire在一起有着关键的作用。然而当越来越多的职责被加入：数据报文的裁剪转换、难以测试和版本控制的编排(orchection)逻辑、服务发现智能路由监控治理分布式事务等All in One的solution将ESB变成了一个可怕的单点梦魇。所以微服务发出了“智能终端哑管道”的呐喊：我们只是需要一个不那么智能的代理处理可靠消息传输，将灵活的逻辑交给服务本身去编配(choreography)吧。
于是在典型的微服务架构里，负载均衡、服务注册发现、分布式追踪等组件以Unix way的方式各司其职。然而在利益诱惑和特性竞争压力之下，很多厂商不断将更多的功能放进他们的中间件，其中为代表的Overambitious API gateways俨然要重新实现占据中心的ESB。如果API gateway只是处理鉴权、限流等横切层逻辑没有问题，如果API gateway开始处理数据转换和业务逻辑编排，你应该提高警惕！
尽管行业在不断发展，但很多时候人们仍然沿用旧的思维，用新的技术去一遍遍重新实现这些旧的反模式。
你总是可以在技术雷达里追踪微服务的state of art，如今这个领域的前沿方向是什么，Service Mesh, Chaos Engineering, 还是Observability as Code？然而 历史 告诉我们，新的技术在解决一些问题的同时，也可能会产生新的问题。更糟糕的是，我们永远无法记住 历史 ，用新的工具更高效地重现旧日问题。
Technologies come and go, Principles stay forever。好在那些架构和实践背后的原则是经久不变的。从操作系统到移动应用都会需要高内聚低耦合的架构，任何软件开发都需要版本控制、自动化构建等实践。谨记这些核心原则、谨记软件被创造出来是为了解决有价值的问题，可以帮我们更好的借鉴 历史 的经验，理解和采纳新的技术。
文/ThougtWorks刘尚奇
本文首发于刘尚奇个人网站：https://6up7.com/a-retrospective-for-enterprise-distributed-application/