参考：
服务架构的演变历史是怎么的？ - 知乎
大白话给你讲分布式架构，3分钟让你学一遍
https://www.jianshu.com/p/d3144d64ba9d
1.1 单体结构所有代码全在一个项目里。
1.1.1 优点- 开发调试方便。
- 事务实现简单。
- 本地调用效率高。
- 代码耦合度高。
- 编译时间长。
- 扩容困难。
- 按照业务隔离维护代码。
- 使用解释性语言。
- 集群部署。
1.2 垂直拆分
当数据库qps成为性能瓶颈时，就需要数据库垂直拆分了。
垂直拆分是根据业务耦合程度，分别把数据放到不同业务边界对应的数据库中，不同的业务代码也根据业务拆分到对应的项目中。由于每个业务服务需要其他数据，就需要链接所有的数据库。
1.2.1 优点- 数据解藕，提升吞吐量。
- 业务边界划分，利于代码维护指引。
- 数据库连接数增加。
- 事务控制复杂。
- 某个业务更新逻辑同步困难。
- 使用连接池。
- 引入分布式事务。
- 业务更新影响到的服务都要重新部署。
当业务复杂度成为开发瓶颈时，就需要服务垂直拆分了。
与垂直拆分的区别是，每个微服务只链接一个数据库，如果需要其他数据需要使用远程调用。
1.3.1 优点- 边界清晰，职责明确，故障隔离。
- 支持微服务粒度动态扩容。
- 可以根据需要为每个微服务进行技术选型。
- 需要处理分布式问题：注册，发现，雪崩，降级，重试，事务，熔断，超时。
- 开发，联调，测试，部署，运维，监控，排查变得复杂。
- 引入新技术，新组件，新框架。
- 开发人员需要更高的技术要求。
业务复杂度成为开发瓶颈时，并不一定要使用微服务。如果开发者严格按照业务划分进行职责划分和代码维护，本地调用也是可以继续使用的。而且微服务的其他优点，都是有替代方案的。
