微服务自我总结

1，微服务发展

参考：

服务架构的演变历史是怎么的？ - 知乎

大白话给你讲分布式架构，3分钟让你学一遍

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，反思

业务复杂度成为开发瓶颈时，并不一定要使用微服务。如果开发者严格按照业务划分进行职责划分和代码维护，本地调用也是可以继续使用的。而且微服务的其他优点，都是有替代方案的。