Go语言微服务架构实战：第二节 微服务简介--走向单体地狱

上节课我们讲了，我们在进行开发一个新的应用时，可以构建一个整体的应用系统，我们称之为单体应用。当我们的应用刚开始起步，业务功能少，代码量可控时，我们还能正常的开发。

局限性

但是，随着系统业务的不断增长，代码量不断增加，我们维护创建的单体应用系统的性能和维护成本都会受到限制，限制了我们继续新增新业务的能力。

单体应用发展趋势

成功的应用有一个趋势，整个项目随着时间推移会变得越来越臃肿。而开发团队在每个迭代开发周期中都要实现更多的用户需求，这意味着需要添加许多行代码。当原来的单体引用运行维护几年之后，小而简单的应用将会逐渐成长成一个庞大的应用。

问题与困境

一旦应用程序成为了一个庞大、复杂的单体应用，整个开发团队可能就会陷入一个痛苦的境地，可能会遇到很多很多的问题，比如说：

• 敏捷开发受挫
  主要问题是：应用程序实在非常复杂，其对于任何一个开发人员来说显得过于庞大。最终，正确修复 bug 和实现新功能变得非常困难而耗时。
  就拿应用启动时间这一项指标来说，应用程序越大，启动时间越长。曾经听说过某应用程序启动需要 40 分钟以上的怪事。如果开发人员经常要重启应用服务器，那么很大一部分时间都是在等待中度过，这将极大的影响我们的工作效率。
• 持续部署受挫
  另一个大问题是，复杂的单体应用本身就是持续部署的障碍。如今，SaaS（Software-as-a-Service软件即服务）应用发展到了可以每天多次将变更推送到生产环境。这对于复杂的单体来说非常困难，因为这需要重新部署整个应用程序才能更新其中任何一部分。联想到之前提到的漫长启动时间，这也不会是什么好事。
  此外，因变更所产生的影响通常不是很明确，开发者很可能需要做大量的手工测试。比如，我们仅仅是修改某个部分的代码，但是因为是全部部署，因此我们必须要重新将整个系统进行全链路测试，这样将耗费非常多额外的时间。
  因此，持续部署是不可能做到的。
• 应用难以扩展
  当不同模块存在资源需求冲突时，单体应用可能难以扩展。例如，一个模块可能会进行密集型图像处理逻辑，理想情况下是部署在云服务器A实例中；另一个模块可能是一个内存数据库，最适合部署到云服务器B实例中。但是，由于这些模块是属于同一个应用，只能被部署在一起，此时就要求运维人员必须在硬件选择上做出妥协和让步，因此就使得原本我们设计的系统处理业务的能力会受到硬件环境的限制。
• 可靠性低
  单体应用的另一个问题是可靠性低。因为所有模块都运行在同一进程中。任何模块的一个 bug，比如内存泄漏，可能会拖垮整个进程。
  此外，由于应用程序的所有实例都是相同的，该错误将影响到整个应用的可用性，对整个应用都造成影响。
• 技术升级困难
  单体应用因为提及庞大，使得采用新框架和语言变得非常困难。假设有50万行代码使用了某个框架编写。如果使用较新的一个框架来重写整个应用，这将非常昂贵（在时间和成本方面）。因此，这对于团队采用新技术，对系统进行技术升级来说是一个非常大的障碍。

最后，经过了上面几个方面的问题的罗列，我们总结一下：当我们开发个业务量小，功能适量的一个项目应用时，通过单体应用的开发，就可以满足我们的开发需求，实现业务功能。当业务量快速增长，系统持续开发迭代时，我们的应用体积和业务复杂程度会越来越高，以至于影响开发人员的开发效率，提高了项目的维护成本，我们的项目会遇到各种瓶颈问题，应用程序的持续扩展能力受到限制，性能也因此受到影响。

既然实际生产环境中遇到了这样的难题，作为项目管理者和项目开发者，就必须想办法解决出现的这些问题。

我们如何做才能解决项目持续迭代后遇到的扩展能力受限和各种瓶颈问题呢？答案是微服务。

---

【注：】本文以上文档，部分内容摘抄自《Docker微服务架构实践》，作者蒋彪。