1 扩展立方体
X轴扩展：在多个实例之间实现请求的负载均衡
Z轴扩展：根据请求的属性路由请求
Y轴扩展：根据功能把应用拆分为服务
2 微服务架构与SOA的异同
SOA与微服务的比较
| SOA | 微服务 | |
|---|---|---|
| 服务间通信 | 智能管道，例如ESB，往往采用重量级协议 | 使用哑管道，例如消息代理，或者服务之间点对点通信，使用轻量级协议，例如REST或gRPC |
| 数据管理 | 全局数据模型并共享数据库 | 每个服务都有自己的数据模型和数据库 |
| 典型服务的规模 | 较大的单体应用 | 较小的服务 |
3 微服务架构的好处与弊端
3.1 好处
- 使大型的复杂应用程序可以持续交付和持续部署
- 它拥有持续交付和持续部署所需要的可测试性
- 它拥有持续交付和持续部署所需要的可部署性
- 它使开放团队能够自主且松散耦合
- 每个服务都相对较小并容易维护
- 服务可以独立部署
- 服务可以独立扩展
- 微服务架构可以实现团队的自治
- 更容易实验和采纳新的技术
- 更好的容错性
3.2 弊端
- 服务的拆分和定义是一项挑战
- 分布式系统带来的各种复杂性，使开放、测试和部署变得更困难
- 当部署跨域多个服务的功能时需要谨慎地协调更多开放团队
- 开发者需要思考到底应该在应用的什么阶段使用微服务架构
4 微服务架构的模式语言
常用的模式结构包括三个重要部分：
- 需求：必须解决的问题
- 结果上下文：采用模式后可能带来的后果
- 好处：这个模式的好处和它解决了什么需求
- 弊端：这个模式的弊端和它没有解决哪些需求
- 问题：使用这个模式所引入的新问题
- 相关模式：5种不同类型的关系
- 前导：前导模式是催生这个模式的需求的模式
- 后续：后续模式是指用来解决当前模式引入的新问题的模式
- 替代：当前模式的替代模式，提供了另外的解决方案
- 泛化：针对一个问题的一般性解决方案
- 特化：针对特定模式的具体解决方案
4.1.1 微服务架构的模式语言概述
- 基础设施相关模式组：这些模式解决通常是在开放环节跟基础设施有关的问题
- 应用基础设施相关模式组：这些模式解决应用层面的基础设施的相关问题
- 应用相关模式组：这些模式解决开发人员面对的具体技术和架构问题
服务拆分的相关模式
根据业务能力分解，围绕业务功能组织服务，以及根据子域分解，子域围绕领域驱动设计(DDD)来组织服务
通信相关的模式
进程间通信是微服务架构的重要组成部分
- 通信风格：使用哪一类进程间通信机制？
- 服务发现：客户端如何获得服务具体实例（如HTTP请求）的IP地址
- 可靠性：在服务不可用的情况下，如何确保服务之间的可靠通信
- 事务性消息：如何将消息发送、事件发布这样的动作与更新业务数据的数据库事务集成
-
实现事务管理的数据一致性相关模式
由于每个服务都有自己的数据库，因此必须使用Saga模式来维护服务之间的数据一致性
在微服务架构中查询数据的相关模式
服务的数据仅可以通过API的方式访问，所以我们不能直接针对服务的数据库执行分布式查询。有些时候我们可以使用API组合模式，逐一调用服务的API然后把所有的返回聚合在一起。多少情况下，你需要使用称之为命令查询职责隔离（CQRS）的方式，来维护一些重要和常用的查询数据视图。
服务部署的相关模式
可观测行的相关模式
健康检查API：可以返回服务健康状态的API
- 日志聚合：把服务产生的日志写入一个集中式的日志服务器，这个服务器可以提供日志搜索，也可以根据日志情况触发报警
- 分布式追踪：为每一个外部请求分配一个唯一的ID，用于在各个服务之间追踪外部请求
- 异常跟踪：把程序异常发送到异常跟踪服务，这个服务会排除重复异常，给开发者发送告警并且跟踪每个异常的解决
- 应用指标：供维护使用的指标，例如计数器，导出到指标服务器
-
实现服务自动化测试的相关模式
消费端驱动的契约测试：验证服务满足客户端所期望的功能
- 消费端契约测试：验证服务的客户端可以正常与服务通信
- 服务组件测试：在隔离的环境中测试服务
解决基础设施的边界问题的相关模式
安全相关模式
5 微服务之上：流程和组织
若有收获，就点个赞吧
0 人点赞
