什么是微服务架构

2012 年，Fred George 分享了题为 Micro Services Architecture-small，short livedservices rather than SOA 的演讲。在这次演讲中，他描述了 2005-2009 年，他和团队成员如何将 100 万行的传统 J2EE 程序，通过解耦、自动化验证等实践，逐渐分解成 20 多个 5000 行代码的小服务。这是对微服务架构进行定义的最早版本。

从 2014 年起，微服务架构由 Martin Fowler、Adrain Cockcroft、Neal Ford 等人接力进行介绍、完善、演进、实践，一直维持着较高的热度，直到现在。

关于微服务架构的定义，可以参考 Martin Fowler 在 2014 年所写的 micro-services 文章。在这篇文章里，Martin Fowler 对微服务架构进行了定义，内容如下：

微服务架构是一种架构模式，它提倡将原本独立的单体应用，拆分成多个小型服务。这些小型服务各自独立运行，服务与服务间的通信采用轻量级通信机制（一般基于 HTTP 协议的 RESTful API），达到互相协调、互相配合的目的。被拆分后的服务都围绕着具体的业务进行构建，每个服务都能独立地进行开发、部署、扩展。由于相互独立且采用轻量级通信机制，因此各个小型服务能够使用不同的语言开发，也可以使用不同的数据存储技术。

图 2-2 是单体应用架构与微服务架构的对比。

图 2-2 左图为单体应用架构。在单体应用中，所有的功能模块都在一个应用程序中编码和部署。使用集群部署，也是复制这个大型的单体应用程序来进行扩展。

图 2-2 右图为微服务架构。在微服务架构的项目中，会把每个独立的功能模块放在一个单独的应用程序中编码和部署，扩展性强。可以按照需求来对这些单独的服务进行分布式部署，不用一股脑儿地把所有服务堆在一起。

微服务架构中各个服务的独立不仅体现在对单体应用的拆分上，还体现在各个小型服务能够使用不同的语言开发，也可以使用不同的数据存储技术。图 2-3 是单体应用架构与微服务架构中的数据存储策略对比。

图2-3 左图为单体应用架构的数据存储策略。在单体应用中，更喜欢用单一的逻辑数据库做持久化存储，各个功能模块使用的数据库存储策略相同。

图2-3 右图为微服务架构的数据存储策略。在微服务架构的项目中，更倾向于让每个独立的服务自行选择数据库存储策略。比如，同一个数据库技术的不同实例，A服务使用部署在 192.168.10.113 服务器上的 MySQL 数据库作为存储介质，B服务选择部署在 192.168.11.104 服务器上的 MySQL 数据库作为存储介质。各个服务也可以选择完全不同的数据库系统，如H服务选择 Redis 和 MySQL 作为存储介质，J 服务选择 MongoDB 作为存储介质，K 服务选择 Elastic Search 和 Redis 作为存储介质。

Martin Fowler 主要对微服务架构与单体应用进行比较，并畅想了微服务架构的未来。

当时，微服务架构基本上还处于理论阶段。虽然也有微服务架构的项目落地，但是当时业界并没有可供广大开发人员进行微服务架构借鉴的最佳实践，没有一套完整的方案能够供广大开发人员使用，普通的开发人员或开发团队想要落地一个微服务架构的项目是非常困难的。对于没有足够资金投入或技术能力不充足的技术团队来说，想要实现微服务架构体系需要做好很多方面的工作才能实现，需要花费的成本还是比较高的。

随后的几年间，越来越多的微服务架构解决方案逐渐出现和开源，这对于众多的技术团队和技术人来说是一个非常大的福音。Java 语言下，主流的就是 Spring Cloud 及其衍生出的一些框架。当然，这是后话了，相关的知识点会在后续章节中进行详细介绍。