0. 巨石应用
- 巨石型应用的好处：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行.
- 对于大规模的复杂应用，巨石型应用会显得特别笨重：要修改一个地方就要将整个应用全部部署（PS：在不同的场景下优势也变成了劣势）；编译时间过长；回归测试周期过长；开发效率降低等。另外，巨石应用不利于更新技术框架，除非你愿意将系统全部重写。
1. 应用的scale cube
- 一个系统的扩展过程：
- （1）x轴，水平复制，即在负载均衡服务器后增加多个web服务器；
- （2）z轴扩展，是对数据库的扩展，即分库分表（分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过hash放在不同的数据库服务器上）；
- （3）y轴扩展，是功能分解，将不同职能的模块分成不同的服务。从y轴这个方向扩展，才能将巨型应用分解为一组不同的服务.
- 系统的服务划分的方法: 1) 按照用例划分; 2) 按照资源划分.
- 分解的目标: 解决巨石应用在业务急剧增长时遇到的问题.
2. 微服务的主要缺点
- 开发人员要处理分布式系统的复杂性, 设计服务之间的通信机制.
- 服务管理的复杂性(Docker).
- 应用微服务架构的时机如何把握? .
3. 架构的关键问题
- 通信机制
- 客户端与服务器之间的通信.
- 添加API Gateway 来讲用户的一个请求, 分解为对内部service 的一系列调用, 从而避免了一次请求, 多次客户端和服务器的交互.
- 内部服务间的通信.
- 基于HTTP 的同步协议(Rest, RPC).
- 基于消息队列的异步消息处理机制.
- 客户端与服务器之间的通信.
- 分布式数据管理
- 处理读请求.
- 处理更新请求.
