基础篇02--微服务架构综述
微服务架构综述
什么是微服务架构
微服务架构是一种架构模式，它提倡将单一的应用程序划分为一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 ---------Martin Fowler
微服务要多“微”？
微服务架构通过对特定业务领域的分析与建模，将复杂的应用分解成小而专一、耦合度低且高度自治的一组服务，每个服务都是很小的应用，那么“微”的程度到底是怎样的？
由于不同语言有不同特点，不同功能的替换或重写很大程度取决于成员的能力，因此代码行数的多少以及重写时间的长短都不能用于衡量“微”。
微服务的“微”并不是一个真正可衡量、看得见、摸得着的微，其所表达是一种设计思想和指导方针。这需要团队觉得合适，在此之前应遵循以下两个基本前提：
- 业务独立性
应保证微服务具有业务独立性的单元，并不是只是为了微而微。
- 团队自主性
团队应该由不同技能、不同角色的成员组成且团队规模要小。
单一职责
编写代码的原则是“高内聚，低耦合”。高内聚指的是一个模块中各个元素彼此结合紧密；低耦合指的是一个完整的系统中，模块与模块之间应尽可能独立存在。符合该原则的系统具有良好的重用性、可维护性和扩展性，能够持续支持业务的发展。
面向对象的设计中有“SOLID”原则，S指的是SRP（Single Responsibility Principle，单一职责原则）：即一个对象应该只有一个发生变化的原因，如果该对象可以被多个原因改变，则其承担了多个职责。
Linux中的每个命令都独立负责一个功能，但命令与命令可以通过管道连接起来可以实现更强大的功能。类似的，对于每个服务而言，我们希望它处理的业务逻辑能够单一，在服务架构层面遵循单一职责原则。即微服务架构中的每个服务都是具有业务逻辑 ，符合高内聚、低耦合原则以及单一职责原则的单元，不同服务通过“管道”方式灵活组合，从而构建庞大的系统。
轻量级通信
服务之间应该通过轻量级的通信机制，实现彼此的互通互联，互相协作。所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，XML或JSON的解析与使用基本与语言无关、平台无关。对于轻量级通信的协议而言，通常基于HTTP，能让服务间的通信变得标准化且无状态化。REST(Representational State Transfer）是实现服务之间互相协作的轻量级通信机制之一。
对于微服务而言，通过使用语言无关、平台无关的轻量级通信机制，使服务与服务之间的协作变得更加标准化，这就意味着团队可以选择更合适的语言、工具或者平台来开发服务本身。
独立性
独立性指在应用交付的过程中，开发、测试以及部署的独立。
传统单块架构应用，所有功能都存在于同一块代码块中，当修改某部分时，容易出现功能之间互相影响，即功能的开发不具有独立性。此外，但代码实现后，需要集成、回归测试，才能保证功能互相配合、正常工作且互不影响，因此测试过程不具有独立性。当测试完毕，单块应用被部署后，由于某个特性存在缺陷将导致部署失败或回滚。
因此单块架构中，功能的开发、测试、构建以及部署耦合度较高。
微服务架构中，每个服务都是独立的业务单元，服务与服务之间是独立的：
- 每个服务都有独立的代码库，从代码库的层面，服务与服务是隔离的；
- 每个服务都有独立的测试机制，从测试的角度而言，服务与服务之间是松耦合的；
- 构建包是独立的，部署流程是也是独立的，服务能运行在不同进程中。从部署角度考虑，服务与服务之间也是高度解耦的
进程隔离
单块架构应用，所有功能都运行在同一进程中，当要部署时，需要停掉当前的应用，无法独立部署。为了提高代码的重用以及可维护性，在应用开发中，开发人员会将重复的代码提取出来，封装成组件（此处指的是可以独立审升级、替换掉的部分）。在传统的单块架构中，组件的通常形态叫共享库，例如JAR包或DLL。应用程序在运行时，所有的组件最终也会被加载到同一进程中运行。
微服务架构中，应用程序由多个服务组成，每个服务都具一个高度自制的独立业务实体。每个服务都能运行在一个独立的操作系统进程中，这意味着不同服务能被部署到不同主机上。理论上，能将多个服务部署到同一节点上，但这样增加了部署和扩展的复杂度。
综上所诉，微服务架构其实是将单一的应用程序划分为一组小的服务，每个服务都具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试以及独立部署。
微服务架构与SOA
面向服务架构SOA，对于复杂的企业IT系统，应按照不同的，可重用的粒度划分，将功能相关的一组功能提供者组织在一起为消费者服务。其目的是为了解决企业内部不同IT系统资源之间无法互联而导致的信息孤岛问题。
微服务与SOA
| SOA实现 | 微服务架构实现 |
|---|---|
| 企业级，自上向下开展实施 | 团队级，自下向上开展实施 |
| 服务由多个子系统组成，力粒度大 | 一个系统被拆分成多个服务，粒度细 |
| 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
| 集成方式复杂（ESB/WS/SOAP） | 集成方式简单（HTTP/REST/JSON） |
| 单块架构系统，相互依赖，部署复杂 | 服务能独立部署 |
微服务的本质
- 服务作为组件
- 围绕业务组织团队
- 关注产品而非项目
- 技术多样性
- 业务数据独立
- 基础设施自动化
- 演进式架构
服务作为组件
软件领域一直提倡使用组件Component的方式将应用模块化并为其构建相对独立的单元。传统实现组件的方式是给独立的部分或者抽取公用部分构建库Library，从而达到解耦和复用的效果。这样的共享库一般是语言相关、平台相关，且与应用程序运行在同一个进程中。即库的变化可能导致整个应用都要更新，重新部署。
将微服务作为组件，与传统使用组件方式最大的区别是，组件可以被独立部署。即，每个服务的变更仅需重新部署自身，不影响其他服务。
因此，微服务架构的一个优势就是能以松散的服务形式，构建可独立化部署的模块化应用。把服务当成组件的另一个优点是，组件和组件之间定义了清晰的、语言无关的、平台无关的接口。许多开发虽然有良好的公共调用接口，但依赖于特定平台和语言，导致组件间耦合度高。
微服务通过语言无关、平台无关的轻量级通信机制协作，灵活性高。不足的是分布式调用比进程内调用更消耗时间，且严重依赖于网络的可靠性与稳定性。
围绕业务组织团队
微服务架构团队组织方式提倡以业务为核心，按照业务能力来组织团队，团队中的成员具有多样性的技能。单块应用架构根据技能划分团队。
关注产品而非项目
项目模式：当项目启动后，企业或组织根据不通过的技能资源池中抽取相关的资源，组成团队并完成项目，
单块架构应用大部分是基于项目模式构建，其弊端如下：
- 团队成员缺乏主人翁精神；
- 难以制定有效的奖惩机制；
- 团队成员缺乏产品成就感。
微服务架构提倡的是采用产品模式构建，即让团队负责整个服务的生命周期，从服务的分析、开发、测试、部署、运维，所有成员的个人目标和团队目标一致，都是为了更有效、高效、以可持续性发展的方式为消费者提供服务。最终目标是通过多个服务的协调、组合实现产品的功能，以及传递价值。
技术多样性
传统的单块应用架构，倾向于采用统一的技术皮平台或方案解决问题。
微服务架构中，提倡针对不同的业务特征选择合适的技术方案，有针对性地解决具体的业务问题。
业务数据独立
传统的单块应用架构，多采用统一的数据存储平台来存储所有数据。随着业务快速发展，需求不断变化，数据变得复杂难以管理，同时随着应用系统的业务逻辑不断更新和发展，数据库不仅承担着数据存储的作用，还承担着不同系统之间的继承作用。
传统的数据库大多是关系型数据库，存储的信息以结构化信息为主，但随着互联网的快速发展，其维护成本会越来越高。
微服务架构提倡服务自主管理其相关的业务数据，这样的优势在于：
- 能随着业务发展，提供业务数据接口集成，而不是以数据库的方式同其他服务集成；
- 能随着业务发展，选择更合适的工具管理或者迁移业务理数据。
基础服务自动化
传统单块架构应用只需要部署一次就能上线。而微服务架构将应用分为多个小的服务，需要对每个服务分别部署，此外每个服务都需要部署带来的健康监控、错误回滚等，这会导致部署和运维的成本随着服务的增多呈指数级增长。
因此微服务需要更稳定的基础设置自动化机制，能够创建运行环境、安装依赖、部署应用。
演进式架构
微服务不是银弹
微服务的优势性在于独立性、单一职责、技术多样性。此外微服务的实施也会推动基础设施自动化以及DevOps文化在团队中的发展，有利于构建全功能的团队。
微服务在实施的过程中需要考虑如下因素：
- 分布式系统的复杂度
- 运维成本
- 部署自动化
- DevOps与组织架构
- 服务间依赖测试
- 服务间依赖管理