上一篇 中提到了单体应用和微服务架构，在 spring 官网的一张架构图中，也展示了网关这个玩意。本篇文章，我们就来了解下API网关，并以此为引子，探讨微服务和中台架构的一些方面。
服务化拆分之后，我们的系统可能会变成这个样子：
看着还是蛮乱的，所以服务调用链追踪就非常重要了。对于客户端来说，这可是苦了客户端，这么多根调用线。这时应用到上一篇的中间层思维，我们的系统可能会变成这个样子：
将调用的复杂性全部交给了橘色的八边形。
此时对于客户端来说，仿佛橘色八边形就是一整个系统，对客户端提供了所有的功能，是所有功能的请求入口。
对于内部服务来说，橘色八边形就相当于了客户端，来调用各个服务。此时，系统结构可以简化为：
橘色八边形就是API网关，客户端通过HTTP协议和网关交互。网关以RPC或者HTTP等方式和内容服务交互。这里的网关从字面意义理解就是：
- 网络的关口：就像内部服务的对外关口一样，起到了关卡的作用。既然是关卡，那么可以提供什么？
- 安全校验
- 限流
- 路由转发
- 聚合
- 实际上这些场景完全可以和生活中的关口对应起来
- 网络协议转换中间层：除了这里的API网关，实际上或许会听说过物联网网关等。他们都起到了协议转换的功能，图中就是将HTTP协议转换成具体的RPC协议
简单回顾下第一篇提到的无状态服务垂直划分下的注册中心，内部服务的负载均衡实际上可以由注册中心去实现，当然也可以用负载均衡组件实现。那么对于API网关呢？
由于API网关是和客户端交互的，使用注册中心的方式不是那么方便。那自然而然就需要用负载均衡组件进行实现，如下图：
通过在前级加入负载均衡等措施，实现API网关本身的高可用。当然负载均衡层可以很复杂，这个后面再说。
既然API网关的负载均衡实现了，那么内部服务的负载均衡呢？如果利用注册中心来实现，那么服务提供者可能如下图：
A1、A2、A3都提供相同的服务，那么"客户端"应该调用哪个呢？如果全部调用A3，那么根本起不到负载均衡的目的。这时，可以将负载均衡算法做到"客户端"中，这个客户端就可以是网关或者其他内部服务。为了保障业务的非入侵性，自然要用到agent这样的代理模式来实现客户端的软负载均衡。
实际上，上面提到的各个方面，就是微服务系统的组成。再来看看 spring官网的图：
- API Gateway ：API网关
- Service Registry：服务注册中心
- Microservices：微服务应用
- Distributed tracing：调用链追踪
- Config server：配置中心。实际上和服务中心类似，但是更倾向于存储配置型信息，毕竟让专业的人做专业的事
光看这些组件，实际上很难去理解微服务。微服务脱离不了业务场景，我们就先不说了。
上一篇提到的服务化应用设计可以类比为 面向对象编程，那么我们的对象设计好了，对象之间的交互也处理好了，是不是就完成了呢？
当然不是，再次回想到分层的思想，有些对象就是属于共性不变的，有些对象就是可能变化的，正所谓分离变化的和不变的~
那么随着不断的拆分沉淀，最终可能形成如下的结构：
其中：
- 物理资源：指的是云服务资源、或者物理服务器资源等等
- K8S平台：上一篇也简单提到过，相当于微服务软件的基础"硬件"设施
- 中间件服务：比如mysql、redis、mq等一系列中间件，属于技术平台
- 基础业务服务：比如一些通用的业务，比如推送业务等等
- 具体业务平台：就是面对不同的前台(web等)应用功能，开发的具体的业务服务
- 前台业务：自然就是WEB、APP等前端应用
按照这种层次划分，各层之间的"对象"定位明确，层内部的对象也拆分清晰。那么就相对容易的实现低耦合、高内聚，也在一定程度上实现了最大的复用性。
所以，在这种架构中，微服务就是：从K8S平台~具体业务平台的整体。其中K8S属于微服务的“硬件支撑”，其余属于微服务的软件部分，只是软件部分中又可以分为：
- 基础软件支撑
- 基础业务支撑
- 具体业务服务
由于具体业务服务和前台业务结合紧密，所以也可以归纳到前台那边。而基础软件支撑和基础业务支撑就可以叫做 中台 ，中台最终是为上层具体业务服务的，又可以叫做 业务中台。
那么后台呢？后台一部分当然是指各种管理系统，另一部分也可以把K8S平台、物理资源等当做后台，因为这是底层的调度层，需要各种监控维护等等。
通过这样的分层架构， 中台 的概念也走入到了我们的视野。业务中台对上层业务提供复用的能力，使得我们的前台业务能快更加快速的开发，也使功能更加容易维护。所以中台就是微服务软件层面的进一步演进。
通过三篇文章，我们整体看了一遍当前的架构概念，算是在宏观上做了一点指引工作。
软件架构或者说系统架构，就是纵横的哲学。
我们，下篇见。下篇开始，正式走进分布式系统的内部，开始领略浩瀚的分布式宇宙。
