微服务
集中式架构 -> 垂直拆分 -> 分布式服务 -> 服务治理（SOA） -> 微服务
选择微服务的动力
外部因素：
- 没有技术银弹可以解决一切需求
- 团队个人技术因素制约着系统发展
- 外部商业环境提出的需求
内部因素：
- 变化十分快的业务
- 大规模 业务复杂的系统
微服务的弊端
- 服务的拆分与定义并不简单，没拆分好的话很有可能构建出一个分布式单体应用
- 分布式系统带来的复杂性
- 分布式事务
- 运维测试
- ...
微服务需要的条件
- 决策者与执行者都能意识到康威定律在软件设计中的关键作用
- 组织中具备一些的对微服务有充分理解、有一定实践经验的技术专家
- 系统应具有以自治为目标的自动化与监控度量能力
概念
- 足够小，内聚性高
- 自治，一个服务就是一个独立的实体
微服务的粒度
- 微服务粒度的下界是它至少应满足独立——能够独立发布、独立部署、独立运行与独立测试，内聚——强相关的功能与数据在同一个服务中处理，完备——一个服务包含至少一项业务实体与对应的完整操作
- 微服务粒度的上界是一个2 Pizza Team能够在一个研发周期内完成的全部需求范围
在这种开发模式中，技术人员也会快速积累业务知识，业务会沉淀到技术人员个人层面。每个人负责某个特性从开发到测试再到运维各方面，也就是DevOps
原则
- 围绕业务建模而非技术建模
- 自动化文化
- 隐藏实现细节
- 去中心化
- 独立部署
- 隔离失败
- 当进行远程调用时，要有机制当调用失败时能将错误隔离在一定的范围内
- 可观察
- 一个服务应提供一定的接口来反映其运行情况
什么时候不适合微服务
对要构建的系统越不熟悉，对系统的各个组件划分也就越困难
所以还是先构建单体系统，再逐步对其拆分
什么时候转微服务
- 单体系统严重制约了研发效率
好处
- 技术异构性
- 弹性，一个服务不可用不会导致级联故障
- 可扩展，一个服务可以运行多个实例
- 简化部署
- 符合组织结构
- 可组合性
- 容易替换
面向服务的架构(SOA)
SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信。
微服务架构可以看做是实现SOA的一种特定方法
其他的分解技术
- 共享库
- 模块
架构师的视角
软件不同于建筑，相对来说，软件的不可预测因素更多，我们应该设计出一个合理的框架，在这个框架可以慢慢演化出正确的系统，也就是生长的架构。
避免对所有事情做出过于详尽的设计，将注意力专注在大方向上
同时，架构设计就是在做取舍，要有原则及实践来指导设计
分区
相对来说，应该多担心区域之间发生的交互，而非区域内的事情
良好的服务应该具有的属性
- 监控
- 每个服务都应该有标准的方式报告其健康状态
- 接口
- 架构的安全性
- 应该有良好的隔离性
代码治理
- 提供范例来指导开发人员如何编写代码
- 提供服务代码模板来简化开发人员的工作
技术债务
短期的利益，长期来看是要付出代价的，应该要维护好这个债务列表
例外管理
一次例外是例外，多次例外就是规则了
系统设计
微服务的架构决定了对架构者的能力要求非常高 而允许平庸开发者的存在
这点与软件工艺理论不谋而合
康威定律
即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式
服务所有权
拥有服务的团队可以对服务做出修改，只要不影响服务的消费者
为什么要共享服务
多个团队共同维护一个服务
- 难以拆分
- 团队的组建是基于技术的，而不是业务
- 人员流动更自由
内部开源
不再采取团队结构，而是让一小部分人称为核心提交者，其他人可以提交PR
孤儿服务
孤儿服务指的是一段时间没有更改的服务
如果团队的组织是按照限界上下文的话，那一个团队可能拥有多个服务，这个孤儿服务在这个团队手上，当发生需求变更时，修改是很容易的。同时，采取了微服务的架构，很多服务都可以进行快速重写
反向的康威定律
- 系统设计会影响组织结构吗？
主链路规划
- 保证最小业务可用性
开源：将边缘计算资源调配给主链路业务
挑战
- 如何划分服务
- 分布式架构带来新的问题
- 运维挑战
生命周期
设计
- 单体应用是否先行
- 划分服务范围
- 服务通信方式
- 可恢复性
部署
- 部署操作标准化
- 持续交付流水线
监控
四层架构
平台层
服务层
实现业务功能或者技术功能的微服务
- 聚合服务与多元服务
- 关键路径：业务线上重要的服务点
通信
- 同步
- 异步
服务边界
用来屏蔽内部实现细节，提供一个外部统一访问点
- API网关
- Backend for frontend
- 为特定群体服务的网关
客户端
- 传统单体客户端
- 微前端
查询
远程调用接口的代价很大，需要对一些查询接口提供批量查询接口
高可靠微服务
- 负载均衡与服务监控
- 限流
- 服务网格
- 引入一个代理来代替服务间的直接通信
故障类型
- 硬件
- 网络通信
- 外部依赖服务
- 内部代码
后备方案
- 降级
- 缓存
- 调用其他服务完成
超时
断路器
为了保护服务
异步通信
可复用的微服务框架
- 服务发现
- 信息收集（可观测性）
- 负载均衡与限流