微服务架构系列 - 开篇：什么是微服务架构
- 1 min微服务架构系列（一）
微服务 vs 服务化
其实在微服务之前，还有服务化的概念，主要应用在 Java 项目中，把传统单机应用通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用，不同的功能模块拆分成独立的服务模块单独部署，以 RPC 接口的形式对外提供服务，这些拆分后的服务模块也是单独开发、测试、部署和运维的。看起来服务化已经解决了单体应用的问题，为什么还会出现微服务呢？
微服务其实是服务化的延伸，从 2014 年开始，得益于以 Docker 为代表的容器化技术的成熟以及 DevOps 文化的兴起，服务化的思想进一步演化，演变为今天我们所熟知的微服务。
那么微服务相比于服务化又有什么不同呢？大体可以总结为以下四点：
- 服务拆分粒度更细：微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务；
- 服务独立部署：每个微服务都严格遵循独立打包部署的准则，互不影响，比如一台物理机上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码；
- 服务独立维护：每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责；
- 服务治理能力要求高：因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。
微服务架构的定义
其实从业界的讨论来看，微服务本身并没有一个严格的定义，不过，ThoughtWorks 的首席科学家 Martin Flowler 的博客描述更加通俗易懂：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下 文，选择合适的语言、工具对其进行构建。
微服务的概念最早即来源于此。
微服务架构的特征
1、多微才够微
微服务架构通过对特定业务领域的分析与建模，将复杂的应用分解成小而专一、耦合度低并 且高度自治的一组服务，每个服务都是很小的应用。
微服务的「微」并不是一个真正可衡量、看得见、摸得着的微。这个「微」所表达的，是一种设计思想和指导方针，是需要团队或者组织共同努力找到一个平衡点。所以，微服务到底有多微，是个仁者见仁，智者见智的问题，最重要的是团队觉得合适。但注意，如果达成「团队觉得合适」的结论，至少还应遵循以下两个基本前提：
- 业务独立性：首先，应保证微服务是具有业务独立性的单元，并不能只是为了微而微；
- 团队自主性：其次，考虑到团队的沟通及协作成本，一般不建议超过10人。当团队超过10人，在沟通，协作上锁耗费的成本会显著增加，这也是大部分敏捷实践里提倡的。
2、单一职责
所谓高内聚，是一个模块内各个元素彼此结合的紧密程度高。低耦合，是指对于一个完整的系统，模块与模块之间，尽可能独立存在。
在面向对象的设计中，更是有放之四海而皆准的「SOLID原则」。SOLID 原则中的 S 表示的是 SRP（Single Responsibility Principle，单一职责原则）：即一个对象应该只有一个发生变化的原因，如果一个对象可被多个原因改变，那么就说明这个对象承担了多个职责。
对于每个服务而言，我们希望它处理的业务逻辑能够单一，在服务架构层面遵循单一职责原则。也就是说，微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过「管道」的方式灵活组合，从而构建出庞大的系统。
3、轻量级通信
服务之间应通过轻量级的通信机制，实现彼此之间的互通互联，互相协作。所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。
对于轻量级通信格式而言，我们熟悉的 XML 或者 JSON ，它们的解析和使用基本与语言无关、平台无关。对于轻量级通信协议而言，通常基于HTTP，能让服务间的通信变得标准化并且无状态化。 REST（Representational State Transfer，表现层状态转化），是实现服务之间互相协作的轻量级通信机制之一。
对于微服务而言通过使用语言无关、平台无关的轻量级通信机制，使服务与服务之间的协作变得更加标准化，也就意味着在保持服务外部通信机制轻量级的情况下，团队可以选择更适合的语言、工具或者平台来开发服务本身。
4、独立性
独立性是指在应用的交付过程中，开发、测试以及部署的独立。
在传统的单体架构应用中，所有功能都存在于同一个代码库中。当修改了代码库中的某个功能，很容易出现功能之间相互影响的情况。尤其是随着代码量、功能的不断增加，风险也会逐渐增加。
除此之外，当多个特性被不同小组实现完毕，需要经过集成、回归测试，团队才有足够的信心，保证功能相互配合、正常工作并且互不影响。因此，测试过程不是一个独立的过程。
当所有测试验证完毕，单体架构应用将被构建成一个部署包，并标记相应的版本。在部署过程中，单体架构部署包将被部署到生产环境，如果其中某个特性存在缺陷，则有可能导致整个部署过程的失败或回滚。
单体应用开发、测试、构建、部署流程图如下：
在微服务架构中，每个服务都是一个独立的业务单元，当对某个服务进行改变时，对其他的服务不会产生影响。换句话说，服务和服务之间是独立的。对于每个服务，都有独立的代码库。当对当前服务的代码进行修改后，并不会影响其他服务。从代码库的层面而言，服务与服务是隔离的。
对于每个服务，都有独立的测试机制，并不担心破坏其他功能而需要建立大范围的回归测试。由于构建包是独立的，部署流程也就能够独立，因此服务能够运行在不同的进程中。
微服务开发、测试、构建、部署流程图如下：
5、进程隔离
所有功能运行在同一个进程中，也就意味着，当对应用进行部署时，必须停掉当前正在运行的应用，部署完成后，再重新启动进程，无法做到独立部署。如果当前某应用中包含定时任务的功能，则要考虑在什么时间窗口适合部署，是否先停掉消息队列或者切断与数据源的联系，以防止数据被读入应用程序内存，但还未处理完，应用就被停止而导致的数据不一致性。
为了提高代码的重用以及可维护性，在应用开发中，我们有时也会将重复的代码提取出来，封装成组件（比如 PHP 中的 Composer 扩展包）。在传统的单体架构应用中，当应用程序在运行期时，所有的组件最终也会被加载到同一个进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体。通常情况下，每个服务都能运行在一个独立的操作系统进程中，这就意味着不同的服务能非常容易的被部署到不同的主机上。作为运行微服务的环境，我们希望它能够保持高度自治性和隔离型。如果多个服务运行在同一个服务器节点上，虽然省去了节点的开销，但是增加了部署和扩展的复杂度。
总而言之，微服务架构其实是将单一的应用程序划分成一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试以及独立部署。