第1章 微服务架构开发

1.1 单体架构应用的困境

何为单体架构应用
顾名思义，一个典型的单体架构应用就是将一个应用中所有的功能都打包在一个WAR文件中，并部署到应用服务器（如Tomcat）中运行

1.1.1 单体架构应用有何缺陷

• 开发维护变复杂

  在业务开展初期, 单体架构应用足以应对公司业务的需求. 但是如果你的公司很吊,业务扩张超迅速, 单体架构应用在 开发, 部署, 运维各方面都会越来越慢, 各种环节都会产生掣肘. 业务量增加, 需求随之增加, 代码量随之增加, 在增加新的需求的时候, 每一次对系统的增,修,调试,部署都会更加复杂, 使得开发效率极低;

• 耦合太高,小问题会演变成大问题

  假设系统某一个地方存在内存泄漏, 由于是单体架构应用,这个时候就会造成整个服务都无法正常提供服务, 引起服务崩溃;

• 数据管理变得艰难

  你会不会遇到这种情况, 团队多人共同开发维护一个单体架构应用,这个时候 数据库工程师小凯 修改了数据库某表的数据结构,但是没有告知后台开发工程师们,这个时候系统就会出错, 虽然错误很容易找到,但是这种事情如果次数变多就会出现各种问题;

• 技术选型单一

  单体架构的应用在开发时,就已经确定好了一个标准的技术栈, 系统研发初期,这种技术栈可以满足公司业务; 系统研发中期, 公司业务急剧增长,这个时候业务放在第一位, 没有时间去考虑重构的事情; 到后面公司业务平稳阶段, 系统已经变得很复杂,如果想进行技术的迭代更新,重构等操作,就会非常耗时耗力.

• 共同开发难度大

  多人开发同一个系统, 非常容易造成代码的冲突. 人越多,冲突的几率就越大;

• 难以进行水平扩展

  在部署上,单体架构应用还会使系统难以进行水平扩展, 因为每个应用实例对服务器来说都需要相同的硬件配置, 简直就是浪费…

1.2 微服务架构

1.2.1 如何定义微服务架构

微服务架构可以说是 如何将功能分解成一系列服务的一种架构模式
微服务架构从结构上来看就是将一个应用拆分成多个松耦合的服务, 这些服务之间通过某种协议(REST, RPC等) 进行互相协作,完成原单体架构下的业务功能,但提供更灵活的部署模式, 更容易扩展, 降低了开发,运维上的复杂度;

我们又该如何理解 微服务中的 服务 呢
服务 是一个可以 独立运行,提供范围有限的功能(可以是业务功能,也有可能是非业务功能) 的 组件.

1.2.2 微服务架构的优势

微服务的设计理念参考了UNIX系统, 每个微服务仅承担一种职责, 并把该职责做到最好.

优点

• 松耦合

  我们可以将微服务看成是一些列服务的集合, 这些服务之间通过并非具体实现的接口及非专有通信协议进行通信(比如REST), 这样只要原接口没有改变,就不会对服务消费者造成影响;

• 抽象

  一个微服务对其数据结构和数据源拥有绝对的控制权, 只有该服务才可以对数据作出修改,其它微服务只有通过该服务才能够访问数据;

• 独立

  每个服务都可以在不影响其它微服务的情况下进行编译, 打包和部署;

• 应对用户需求的多样性

  微服务架构可以让我们轻松 应对不同客户的特殊需求,通过定义良好的接口,可以让不同的微服务承担不同的责任,

• 更高可用性和弹性

  微服务架构可以认为是一种去中心化的应用, 每个微服务都可以随时上线或下线;

1.2.3 微服务架构的缺点

缺点

• 可用性降低

• 处理分布式事务棘手

• 全能对象组织业务拆分

God Classes : 如商城系统中的订单对象, 订单几乎会涉及电商应用的每一个业务,它会阻止你进行业务拆分;

• 学习难度曲线加大

• 组织架构变更

1.3 微服务架构设计

微服务架构设计,简单分以下三步:

1. 把应用的需求定义出来
2. 识别出采用微服务架构时应用中所包含的所有服务;
3. 将第一步所定义出的关键需其作为架构需求的场景来描述服务之间如何进行协作;

注意:
在识别应用中的服务时
首先 专注于 业务. 通过业务逻辑的视角可以快速有效的将核心微服务识别出来. 之后可以围绕核心服务把相关联的服务都定义出来,并对这些服务进行分组,合并处理, 最终完整定义出应用的一系列微服务;

当识别出应用的每一个微服务后, 我们就需要考虑这些微服务之间如何进行协作. 定义每个微服务之间协作关系最有效的方式就是根据每一个业务进行分析, 有些业务场景可能只需要某一个服务就可以完成,有些业务场景则可能需要两个或者多个服务才可以;

1.3.1 微服务粒度

设计微服务应先专注于各个服务之间的交互, 先把他们划分成粗粒度的服务, 随着系统的升级和功能的提升,再将这些颗粒度的服务逐渐细化,形成更为合理的微服务粒度;

1.3.1.1 微服务再拆分的实际

当我们发现在一个微服务中已经承担了多种职责时, 就该考虑对微服务进行再拆分;

1.3.1.2 衡量微服务力度是否合适

粗粒度的微服务

对于过于粗粒度的微服务来说, 该服务一定承担了太多的职责, 往往在服务中塞了过多的业务逻辑和业务规则,而且业务流程非常复杂, 难以理解(给人一种依然在开发单体系统一样). 对于粗粒度的微服务,另一个明显的表现就是拥有众多数据的管理权限;

细粒度的微服务

如果微服务力度太细, 一个明显的特征就是每一个微服务几乎都需要和其他的微服务进行沟通, 每个微服务只承担其中很少量的业务处理, 然后就交给其它微服务处理,造成了一个外部请求需要经过太多的微服务才能够完成处理. 每一个微服务都依赖于其他微服务,同时又被其它微服务所依赖;

1.3.2 微服务拆分原则

• 单一职责原则(SRP)
• 共同封闭原则(CCP)

单一职责原则(Single Responsibility Principle, SRP)
对于微服务设计来说,一个微服务承担太多职责的话,会导致微服务业务之间的耦合, 我们需要保持微服务的单一性,从而提升应用的稳定性.(发邮件就只发邮件)

共同封闭原则(Common Closure Principle, CCP)
包中的所有的类对于同一种性质的变化应该是共同封闭的. 一个变化若对一个封闭的包产生影响,则将对该包中的所有类产生影响,而对其他包则不造成任何影响;
共同封闭原则,可以将那些在业务上联系紧密,由于同一个原因而改变的服务组织在一个微服务中. 这样我们可以减少微服务的数量, 另外一方面当业务发生改变时我们只需要对其中一个服务进行修改即可.

1.3.3 服务自治原则

自治范围

• 代码和数据
• 微服务的运行和维护管理

数据管理的私有化(只允许开发该微服务的人对数据有操作权限)，可以进一步降低业务之间的耦合

微服务架构中的数据自治是指每个微服务拥有其业务领域对象下的数据，只有该微服务可以对这些数据进行操作，而其他微服务只有通过该微服务才能访问到这些数据，不能直接通过数据库进行沟通。

1.3.4 微服务交互原则

我们基本会使用以下原则作为微服务接口设计的准则：

• 使用REST协议

  REST在微服务互相调用之间起着非常重要的作用，强烈建议使用HTTP作为服务的调用协议，并在服务处理上使用HTTP标准动词（GET PUT POST DELETE）

• 使用URI表达

  服务端点的URI应该能够清晰表达出我们所要解决的问题,提供的方法,相应资源信息以及资源之间的关联关系;

• 使用JSON数据格式

• 使用HTTP标准状态码

  HTTP协议本身具有非常丰富的状态码, 使用这些状态码来作为服务调用结果的状态是非常合适的;

1.3.5 微服务架构迁移

切记 --> 不要大规模进行重构,而是一小步一小步来;

与大规模进行重构相反,我们在进行微服务架构迁移时可以使用Martin Fowler 提出的 绞杀(Strangler)模式.

即,在迁移时应首先围绕着传统应用开发出新的微服务应用,并逐渐替代传统应用中的部分业务功能. 通过这种方式逐步构建微服务应用,并替代,兼容整合旧的传统应用,直到微服务承担全部应用功能;

1.4 不适合使用微服务架构的情形

1. 构件分不是架构非常吃力时(此处通常是指公司技术能力不够的情况);
2. 服务器蔓延时;
3. 采用小型应用,快速产品原型时;
4. 对数据事务的一致性有一定要求时(分布式事务的一致性,一直都是分布式系统的一个痛点和难题);