为什么要用微服务？单体应用他不香吗？

前言

最近看了一篇文章 千万并发，阿里淘宝的 14 次架构演进之路.

反思为什么要用微服务架构，他们到底有什么区别？凡事都要权衡他的利与弊

下面我们来说说他们的区别

单体服务

什么是单体应用？简单的说就是不管啥功能都往一个应用里写，比如电商系统。用户功能、商品功能、订单功能等等，都往一个应用里写。

好处：

1. 本地开发调试方便，直接起一个项目，调试也是在一个进程内，没有冗长跨进程的调用链，出错可快速定位。
2. 本地的函数调用，没有网络调用的开销。
3. 简单粗暴，快速交付
4. 日志以及调用链路都在一起
5. 对比微服务事物机制简单

坏处：

1. 系统耦合性高，导致开发效率低下。你不能保证你修改的功能模块不会影响到其他功能
2. 语言单一，不能根据场景选择更加合适的语言
3. 系统的整体可靠性不高，存在单点故障风险，一个挂了全部挂
4. 系统不易于扩展部署，如增加手机APP或者公众号业务，单体应用支撑不了，需要NG负载均衡多个单体应用，代码重复性高，资源浪费

微服务

什么是微服务？ 根据不同业务拆分出不同的服务，并且会整理出当前公共的功能变成一个公共服务，每个服务独立部署，独立运行，代码进行了物理隔离。数据库也会拆分出来每个服务维护自己的数据库，数据库之间的数据通过接口传递，而不再是直接访问

好处：

1. 系统的耦合度降低，模块之间的边界清晰，都按业务物理隔离了
2. 系统整体可靠性变高。
3. 可根据服务横向扩展部署
4. 技术选型丰富，不同的服务可以利用不同的技术或语言实现

坏处：

1. 调用链路变长，调用增加了网络的开销，性能变差，出问题难跟踪
2. 微服务架构整个应用分散成多个服务以及日志，对日志定位故障点非常困难
3. 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的
4. 随着服务的增多，人力成本增大
5. 服务器硬件资源以及维护成本大大增加

引出问题以及解决方案

调用链路变长

定位： 引入分布式链路追踪服务
分析： 引入ELK来方便日志的查看

服务治理，动态扩容

引入注册中心和配置中心，以及网关

防止网络之间服务调用不可靠

限流措施、熔断措施、降级策略

多服务事物一致性

分布式事物解决方案