IMG_20161026_142532.jpg
随着业务发展，业务功能的堆叠和复杂化，团队壮大，代码量也增加，各种问题开始凸显：
- 代码结构开始变得混乱，难以管理，提交冲突，改一处引多处。
- 沟通成本变高。
- 代码维护难：“修复越多，缺陷越多”。
- 引入和集成技术变得困难，依赖版本冲突，新特性无法使用。
最后开发效率也开始下降，代码维护的成本提高。
上线后稳定性不高，更大几率的影响可靠性和可用性，所有功能都运行在一个进程中，任何一个功能中出现bug，比如内存泄露，逻辑死循环耗尽CPU等，可以导致整个应用挂掉。
其中几个高并发功能，也不得不部署将所有功能增加部署实例，内存和CPU利用不够充分，灵活性也变差。
其缺点也很明显：
- 运维工作量增加，应用运维管理复杂。
- 代码重复率增加，团队自治带来的重复劳动。
- 分布式系统固有的复杂性和缺点：网络延迟，不可靠，负载均衡，调用，事务等等
微服务架构可以从一定程度上解决或缓解上述问题，但它也不是万能的，但也带来了一系列的非功能性需求，比如说分布式事务、自动化运维，服务发现，服务路由等额外需求，但其带来的好处以及克服其缺点总结如下：
- 服务发现带来很多自运维特性。
- 单一职责原则在各种各种场景的解耦合
- 业务开发：只关注小团队所熟悉和负责的业务，做到专而精，并且容易实现持续交付。
- 代码管理：无论多git repository还是多maven module都可以做到一般的代码隔离，尤其是积累很多年的代码，拆分后更清晰不混乱，易管理。
- 技术实现：处理的业务不同，可能会采取不同的技术栈，如果是单体，依赖有冲突的时候不得不花时间fix冲突或者妥协放弃集成。微服务拆分后，相互独立，集成新技术更容易。
- 测试：尤其是对单元测试和自动化测试更有好处，但对于整个集成测试却带来了挑战，通过可视化运维系统和一个完整的测试环境搭建，以及架构上适当调整，成熟化测试环境后，可以弥补这种不便。
- 独立部署，快速而出错几率比较低，但运维量比较大，但通过可视化自动运维系统来克服。
- 运行时的隔离，这个是显而易见的，就跟汽车道路一样，谁跑谁的道，互补干扰。
- 分布式事务也有很多成熟的参考方案来解决：补偿型，可靠事件型，TCC型等。
- 服务调用上，可以通过超时、隔离、服务发现负载均衡提高可用性和可靠性。
- 网络延迟，可以采用轻量级协议和连接池技术等来弥补。
网友评论