| 类型 | 单体 | 微服务 |
|---|---|---|
| 部署速度 | 慢 | 快 |
| 扩展能力 | 低 | 高 |
| 复用能力 | 低 | 高 |
| 复杂度 | 高 | 低 |
| 耦合度 | 高 | 低 |
| 调试 | 容易 | 困难 |
| 问题排查 | 容易 | 困难 |
| 性能 | 高 | 差 |
单体应用：随着时间的积累代码量越来越大构建速度会越来越慢，部署也会越来越慢，随着代码的积累各种代码的耦合度会越来越高，技术债务逐步上升代码的扩展能力持续下降，复用困难，业务为了避免各种技术债务复杂度会越来越高。因为技术债务较高当开发人员离职后，继任者需要大量的时间去熟悉系统和代码，造成经济损失。但是在开发中单体服务代码集中日志集中所以调试简单，问题排查过程简单。而且单体中不需要额外的服务调用所以性能会更好一点
微服务应用：通过设计将业务进行拆分，降低各个服务间的耦合，每个服务独立部署并且实现服务轻量化，所以构建迅速。因为各个服务独立与其他服务耦合度低所以复用能力和扩展能力更强，每个服务更专注自己的业务领域所以业务的复杂度更低。复杂度更低即使开发人员离职，继任者只需要了解自己需要负责的服务就可以胜任。但是微服务因为做了拆分所以数据的交换需要进行进程通讯，而且同一个请求可能经过多个服务。进程间的通讯会对性能产生影响，请求经过多个服务会使数据的事务实施困难，以及单个请求的异常因为链路太长定位问题困难。
针对微服务的缺点我们的弥补措施：
微服务之间互相调用网络请求的瓶颈：尽量的明确接口数据长度，使用缓存，减少服务间的交互，更改交互方式为rpc
调试和问题排查：问题排查主要是分为两部分
1.问题的定位问题： 引入skywalking来对全链路进行追踪
2.问题的上下文信息获取：引入ELK日志管理解决方案，对日志进行集中，并通过skywalking提供的唯一ID对数据进行查询分析
事务：事务可以根据业务情况来使用诸如两段式提交的解决方案或者使用最终一致性解决方案来解决