第二部分、设计

第三章、微服务应用的架构

• 微服务应用应该有个全局视图

• 微服务的四层架构：平台层，服务层，边界层和客户端层

• 服务通信的模式

• 作为应用边界的 API 网关和消费者驱动型门面设计深入了解应用的业务领域是成功落地实现的关键之一。

3.1、整体架构

3.1.1、从单体应用到微服务

单体应用的三层架构，典型的 MVC 模式，数据层，业务逻辑层，展示层。应用还可以根据不同业务领域进行垂直切分。

微服务应用中，微服务的范围划分-如何定义微服务的边界和职责。

3.1.2、架构师的角色

• 拉齐和组织的远大战略目标（基于公司/组织的战略规划）

• 团队共同承担一套通用的技术价值观和期望（团队文化）

• 跨领域的内容---诸如可观察性、部署、服务间通信----满足不同团队的需要（技术基础设施）

• 面对变化，整个应用是灵活可扩展的（应用设计的良好扩展性）

3.1.3、架构准则

准则是指团队为了实现更高的目标而要遵循的一套指南规则。准则用于指导团队如何实践。

3.1.4、微服务应用的 4 层架构

• 平台层

• 服务层

• 边界层

• 客户端层

3.2、微服务平台

一个具有鲁棒性的平台层既能降低整体的实现成本，又能够提升整体的稳定性，并且提高开发的速度。

3.3、服务层

3.3.1、功能

• 业务能力（组织为创造价值和实现业务目标所做的工作。划到业务功能的微服务直接体现的是业务目标）

• 技术能力（通过实现共享的技术功能支持其他服务）

3.3.2、聚合与多元服务

靠近系统边界的服务会和某些服务交互以聚合它们的输出（这种服务称为聚合器）

协调下层多个服务的工作（这种服务称为协调器）

聚合器服务通过将底层服务的数据进行关联来实现查询服务，协调器服务会向下游服务发出各种命令来编配它们的行动。个人理解的是这里更像是统一的网关层进行了聚合和协调处理

3.3.3、关键路径和非关键路径

关键路径上的服务越多，系统出现故障的可能性就越高。所以需要对其进行相关梳理，实际上是对微服务的整个稳定性的可观测性有保障。

3.4、通信

网络通信，同步或者异步，网络的稳定因素 都是作为服务的可靠性考核因素。

3.4.1、何时使用同步消息

执行新的操作前必须判断一个操作的数据结果

• 选择传输方式

• 时延、语言支持、规范性

• 缺点

• 服务之间耦合严重

3.4.2、何时使用异步消息

新服务不需要对已有的服务进行修改

• 缺点

• 服务之间交互不可预测--需要依赖监控观测行为

3.4.3、异步通信模式

• 赢者通吃（作业队列）1 对 1

• 发布-订阅 1 对多

3.4.5、服务定位

以服务注册中心作为真实数据来源的服务发现方案。服务发现需要依赖于所部署的应用的拓扑结构的复杂度。

不同代理和负载均衡方案可以访问 bit.ly/2o86ShQ

3.5、服务边界

哪些可以作为这里面的归类呢？

• 认证和授权---验证 API 客户端的身份和权限

• 限流---对客户端的滥用进行防卫

• 缓存----降低后端的整体的负载

• 日志和指标收集----可以对客户端的请求进行分析和监控

3.5.1、API 网关

网关的详细了解可以参考我之前的文章：https://xiaochengxinyizhan.blog.csdn.net/article/details/77162624

3.5.2、服务于前端的后端

网关的边界需要清晰，否则后期蔓延导致臃肿。

3.5.3、消费者驱动网关

GraphQL API 通过 Apollo 或者其他方式将 REST ful 的后端服务封装。

3.6、客户端

前端也可以微服务，将单体应用改为微前端。可以参考 Micro Frontends 和 Zalando 的 Mosaic 项目。