3G Eden
RSS近日，Java Code Geeks发表了一篇文章，分析了单体应用与微服务的优缺点，并建议使用微服务重构现有的应用程序。
通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它归档格式。单体应用有如下优点：
- 为人所熟知：现有的大部分工具、应用服务器、框架和脚本都是这种应用程序；
- IDE友好：像NetBeans、Eclipse、IntelliJ这些开发环境都是针对开发、部署、调试这样的单个应用而设计的；
- 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；
- 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；
- 容易部署：只需将单个归档文件复制到单个目录下。
目前为止，单体应用已经很好地服务了我们，未来无疑还会继续发挥重要作用。但是，不管如何模块化，单体应用最终都会因为团队壮大、成员变动、应用范围扩展等出现问题。下面是单体应用的一些不足：
- 不够灵活：对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
- 妨碍持续交付：单体应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重；
- 受技术栈限制：对于这类应用，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具，无法根据具体的场景做出其它选择；
- 技术债务：“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，单体应用尤其如此。系统设计或写好的代码难以修改，因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭，这必然会增加应用程序的技术债务。
而随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序。这里的“微”不是针对代码行数而言，而是说服务的范围限定到单个功能。微服务有如下特点：
- 领域驱动设计：应用程序功能分解可以通过Eric Evans在《领域驱动设计》中明确定义的规则实现；每个团队负责与一个领域或业务功能相关的全部开发；团队拥有全系列的开发人员，具备用户界面、业务逻辑和持久化存储等方面的开发技能；
- 单一职责原则：每个服务应该负责该功能的一个单独的部分，这是SOLID原则之一；
- 明确发布接口：每个服务都会发布一个定义明确的接口，而且保持不变；服务消费者只关心接口，而对于被消费的服务没有任何运行依赖；
- 独立部署、升级、扩展和替换：每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级，每个服务都可以沿着《Art of Scalability》一书定义的X轴和Z轴进行扩展；
- 可以异构/采用多种语言：每个服务的实现细节都与其它服务无关，这使得服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、持久化存储、工具和方法；
- 轻量级通信：服务通信使用轻量级的通信协议，例如，同步的REST，异步的AMQP、STOMP、MQTT等。
相应地，微服务具有如下优点：
- 易于开发、理解和维护；
- 比单体应用启动快；
- 局部修改很容易部署，有利于持续集成和持续交付；
- 故障隔离，一个服务出现问题不会影响整个应用；
- 不会受限于任何技术栈。
微服务看上去像一枚银弹，可以解决许多软件开发方面的问题。这看上去很美好，但并不易于实现。微服务会极大地增加运维工作量，InfoWorld在一篇文章中明确指出：
使用微服务，一些技术债务势必从开发转到运维，因此，你最好有一个一流的开发运维团队。
因此，微服务对基础设施提出了一些额外的需求。通常，我们将它们总称为NoOps，本质上讲，就是一组服务，提供一个更好的应用程序部署流程并确保其运行，包括服务复制、服务发现、服务恢复和服务监控。
不过，即使具备了上述条件，也并不是说就要抛弃现有的应用程序，在大多数情况下，我们无法做到。因此，我们要构建一种方法，依据它使用微服务重构现有的应用程序。虽然重构过程并不简单，但长远来看，重构一个单体应用可以一次性偿还所有的技术债务。
Netflix是使用微服务的一个典型代表，它发表了数篇文章（1、2、3、4、5、6）分享采用微服务的一些经验，感兴趣的读者可以进一步阅读。
