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