1、从传统单体架构到服务化架构

1.1 JEE架构

JEE将企业级软件架构分为三个层级 ： Web 层、业务逻辑层和数据存取层。对应的职能团队，主要包括：用户 交互 UI 团队、后台业务逻辑处理团

队、 数据存取 ORM 团队与 DBA 团队等。

1.2 SSH架构

MVC模型：

SSH架构层次：实现交互 UI 接口的 Web MVC 层、实现业务逻辑的 Spring 层及实现对象关系映射的 Hibernate层。

每个层级的实现比JEE对应的层次更简单、更轻量级 ，不需要开启整个应用服务器即可测试和验证，极大提高了开发效率，这得益于 Spring 框架的控制翻转理念。

1.3 服务化架构

从 JEE 时代到 SSH 时代，服务的特点仍然是单体化，业务逻辑仍然糯合在一个项目中。传统 JEE 和 SSH 无法满足对海量用户发起的高井发请求进行处理的需求，无法突破稿合在一起的模块化组件的性能瓶颈，单一进程己经无法满足需求，并且水平扩展的能力也是很有限的。于是SOA 出现了， SOA 代表面向服务的架构，俗称服务化。

SOA特点：

良好的对外接口，通过网络协议对外提供服务。服务之间松耦合。

单个服务发生改变，不影响整个流程。只要接口不变，对外是透明的。

通信格式XML，后来被JSON取代。

服务的可重用性。

SOA可以最大化使用内部和外部的公共服务。

SOA 的两个主流实现方式： Web Service 和 ESB。

Web Service技术使每个服务之间是对等的，并且互相是解耦的，通过 WSDL 定义的服务发现接口进行访问 ，并通过 SOAP 协议进行通信 。 SOAP 协议通常是一种在 HTTP 或者 HTTPS通道上传输 X岛伍数据来实现的协议，但是每个服务都要依赖中心化 Web Service 目录来发现现存的服务。

ESB 的核心在于企业服务总线的功能和职责。

监控和控制服务之间的消息路由。

控制可插拔的服务化。

解析服务之间通信的内容和格式。

统一编排信息处理流程。

冗余备份。

2、从服务化到微服务

2.1 微服务架构的产生

Web Service 的问题：

依赖中心化的服务发现机制。

SOAP使用XML冗余大。

服务化管理和治理设施不完善。

ESB 的问题：

ESB 虽然是 SOA 实现的一种方式，却更多地体现了系统集成的便利性，通过统一的服务总线将服务组合在一起，并提供组合的业务流程服务。

组合在 ESB 上的服务本身可能是一个过重的整体服务，或者是传统的 JEE 服务等。

ESB 视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在。

对于总线本身的中心化的管理模型，系统变更影响的范围经常会随之扩大。

微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用 RESTful 风格的 API 形式来通信 ，因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点，当然，也可以通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现 。

微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。

2.2 微服务架构与传统单体架构的对比

微服务的架构：

微服务把每一个职责单一的功能放在一个独立的服务中 。

每个服务运行在一个单独的进程中。

每个服务有多个实例运行。运行在容器化的平台，可以平滑伸缩。

每个服务有自己的数据存储。独立的数据，缓存，消息队列等。

每个服务有独立的运营平台。每个服务高度自治，内部变化对外透明。

每个服务可以根据性能独立地水平伸缩。

传统单体架构的伸缩架构：

传统单体架构将所有模块化组件混合后运行在同一个服务JVM进程中 。

可对包含多个模块化组件的整体JVM进程进行水平扩展，而无法对某个模块化组件进行水平扩展。

某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线。

模块间的依赖将会不清晰，互相糯合、互相依赖。

2.3 微服务架构与 SOA 服务化的对比

微服务架构与 SOA 服务化虽然一脉相承，却略有不同。

目的不同。SOA强调异构服务之间协作和集成。微服务目的是拆分，实现敏捷开发部署。

部署方式不同。拆分成多个小服务，使用敏捷扩容，Docker实现自动化容器管理。SOA服务将多个服务打包在一起，部署在一个服务器上。

服务粒度不同。微服务拆分粒度更细，职责单一。通过服务组合实现业务流程。SOA对粒度没有要求，通常是粗粒度的。

3、微服务架构的核心要点和实现原理

3.1 微服务架构中职能团队的划分

微服务架构按照业务的功能进行划分，每个单一的业务功能叫作一个服务，每个服务对应一个独立的职能团队，团队里包含用户交互UI设计师、后台服务开发人员、DBA、运营和运维人员。

3.2 微服务的去中心化治理

微服务架构倡导去中心化的服务管理和治理，尽量不设置中心化的管理服务，最差也需要在中心化的管理服务宕机时有替代方案和设计。

3.3 微服务的交互模式

读者容错模式：微服务化中服务提供者和消费者之间如何对接口的改变进行容错。

消费者驱动契约模式：用来定义服务化中服务之间交互接口改变的最佳规则。

去数据共享模式：不要共享缓存和数据库等资源，也不要使用总线模式，服务之间的通信和交互只能依赖定义良好的接口，通常使用RESTful样式的API或者透明的RPC调用框架。

共享数据集成的缺点

微服务之间的交互除了接口契约，还存在数据存储契约。

上游数据格式变化，可能导致下游的处理逻辑出问题。

多个服务共享一个资源服务，资源服务的运维难以划清职责和界限。

多机房部署，需要考虑到服务和资源的路由情况，跨机房调用，难以实现服务自治。

3.4 微服务的分解和组合模式

使用微服务架构划分服务和团队是微服务架构实施的重要一步，良好的划分和拆分使系统达到松耦合和高内聚的效果，然后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。

组合微服务方式

服务代理模式：最简单的服务组合模式，它根据业务的需求选择调用后端的某个服务。在返回给使用端之前，代理可以对后端服务的输出进行加工，也可以直接把后端服务的返回结果返回给使用端。一般会对读请求切换设计一个开关，开关打开时查询新系统，开关关闭时查询老系统。典型的案例：平滑的系统迁移。

服务聚合模式：最常用的服务组合模式，它根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。

聚合服务可以是前端应用

也可以是纯后台服务

服务串联模式：类似于一个工作流，服务直接的调用通常使用同步的RESTful风格的远程调用实现。优点是在非串联服务的正后面增加节点，串联服务无感知；缺点是不建议服务的层级太多。

服务分支模式：是服务代理模式、服务聚合模式和服务串联模式相结合的产物。

以电商平台的支付服务架构为例

服务异步消息模式：

以电商平台交易完成后向物流系统发起消息通知为例

服务共享数据模式：其实是反模式，用于单元化架构和遗留的整体服务。

3.5 微服务的容错模式

网络通信是不稳定、不可靠的，一个服务依赖的服务可能出错、超时或者宕机。

舱壁隔离模式：微服务容器分组和线程池隔离

熔断模式

限流模式：计数器，令牌桶，信号量

失效转移模式：当发生了熔断和限流时，采用快速失败的策略，直接返回使用方错误；若有备份服务，迅速切换；有可能是某台机器出问题，采用重试方式。

3.6 微服务的粒度

微服务初衷是按照业务的功能进行拆分，直到服务功能和职责单一，甚至拆到不可再拆。原则是拆分到可以合理排版底层的自服务来获得相应的组合服务，同时考虑团队人员分配。

4、Java平台微服务架构的项目组织形式

4.1 微服务项目的依赖关系

一方库：本服务在JVM进程内依赖的Jar包。

二方库：在服务外通过网络通信或者RPC调用的服务的Jar包。

三方库：所依赖的其他公司或者组织提供的服务或者模块。

4.2 微服务项目的层级结构

4.3 微服务项目的持续发布

微服务项目需要实现自动化的持续部署和持续集成的功能，包括：代码管理、自动编译、发布QA、自动化测试、性能测试、准生产部署和测试、生产环境发布等。

5、服务化管理和治理框架的技术选型

5.1 RPC

5.2 服务化

SOA服务化时代的服务化框架和平台

5.3 微服务