Spring Cloud 微服务入门篇

什么是微服务架构 Microservice

微服架构是在移动互联网时代崛起的新架构模式。现在架构模式一般称为Microservice，本身叫微服务。现在的互联网公司，尤其是国内阿里、腾讯、微博、京东、拼多多等，严格来说都是微服务架构。

微服务的发展历史

回顾历史，这么多年架构的发展最具有代表性是淘宝和腾讯，但是腾讯更像 QQ 与微信的架构，后台主要以 C++为主，是典型的分布式架构软件，直播类、社交类的抖音也是一个典型的微服架构。

起步较早的淘宝经历过三大阶段，单体到 SOA，再到微服务。微服务架构是 2000年到 2010 年之间非常火爆的架构，尤其是一些大型的银行项目。同时，它也是分布式架构非常重要的阶段，是一个代表性的架构。

微服务的定义

1）微服务架构模式
2）Microservice
3）Dr. Peter Rodgers2005 Cloud Computing Expo 技术大会上提出概念
4）2007, Netflix 开始向微服务架构师进发
5）并最终开源了自己研发的 Java 微服务框架
6）开源社区命名为 Spring Cloud
7）微服务是一种新型的 软件架构风格
8）把单个巨型服务应用，分解为多个独立的、微小的服务程序
9）单独部署
10）单独伸缩
11）去中心化：数据中心、管理中心
12）敏捷性、灵活性、需求变化，更加高效的软件架构模式

微服务架构诞生在 SOS，最早的时候并不叫微服务架构，而是叫 Micro Web Service，指微小的 web service 程序，使用 Java 写了一套轻量级的微服务架构的解决方案，是移动互联网时代很重要的一个标志。

目前，微服务框架以 recipe 风格为主的一个很重要的原因，后续无论是去中心化、敏捷开发、单独部署等都是随着程序的微服务化快速开发与部署，逐步诞生了一系列的经典的工具，辅助用户提升业务应用的开发部署模式与效率。

微小的服务

1）微服务架构：将单个应用拆分成多个独立的、微小的服务。
2）每个小服务程序运行在独立的进程中。
3）服务与服务之间通过轻量协议通信。
4）通信机制互相协作、互相配合,从而为终端用户提供业务价值。
5）每个小服务，可以采用不同的语言、框架、工具 独立开发、测试、部署、运维。
6）微服务：独立的小服务。

Microservice 的简称过来就是微服务，实际指微小的服务程序，之前各个服务程序都在一个项目中，现在拆开方便进行各个功能单独迭代升级。移动互联网中微服务迭代的非常快，无论是淘宝的支付宝，还是微信、微博，其他的 APP 都是微服务加工。设置手机默认浏览器也是，子功能模块它其实都在单独的进行功能迭代的，尤其是国内定制的浏览器，360 浏览器，腾讯浏览器，百度浏览器其实里面在各种功能基本上也都单独进行迭代的。杀毒软件也有各种不同的背后通信数据采集的机制。

微服务

简而言之，微服务架构风格是一种将单个应用程序开发为一套小服务程序的方法，每个小服务都在自己的进程中运行，并使用轻量级协议（通常是 HTTP 协议）进行通信。这些服务围绕业务功能构建，可通过全自动部署机制独立部署。这些服务很少使用中心化管理模式，可以用不同的编程语言开发，也可能使用不同的数据存储技术。

基本上认为现在微服务架构，通信的接口都是 Rest API，以 HTTP+Jason 格式进行交互。相比传统的 rpc、dubbo、web service 重量级的框架来说，有些业务场景需要更高性能的通信协议，后续会看到一些新版本的微服务框架在不断迭代和进化。

微服务的发展历史

微服务并非全新的架构，回顾计算机历史发展史，会发现基本上无论算法、框架还是理论知识，都有一个明显的时间线或者依赖关系。后续出现的框架一定比前面的框架设计的更好，因为它是借鉴或者总结前面经典的设计思想模式，然后进行改进，代表性公司如麦飞，内部实践并且把框架全部贡献给社区，做出了很大贡献。

Netflix 后续将微服务架构的解决方案全部开源，是 Spring Cloud 最早的一批微服务框架，目前社区也在用

1. 微服务架构的发展历史

1）Dr. Peter Rodgers 在2005年的Web Services Edge conference 大会上演讲，PPT 第 4 页引入了“Micro-Web-Services 一词
2）2007 年，Netflix 开始走向全面拆分巨型 SOA 服务的漫长道路。
3）2011 年 5 月在威尼斯附近举办的软件架构师研讨会使用了“微服务”“microservices”一词。
4）2012 Netflix 开源了所有的微服务相关工具框架的源码
5）2012 年 5 月, 同一个组织宣布“microservices 是最恰当的名词。
6）James Lewis 在 2012 年 4 月 第 33 届 Degree in Kraków in Microservices-Java, the Unix Way,大会上案例研究分享时提出了类似的想法， Fred George 也大约在这个时间提出了类似观点.
7）Netflix 公司的 Adrian Cockcroft, 称为：“fine grained SOA“
8）2014 年 4 月 25 号，Martin Fowler 发表 Microservices a definition of this new architectural term
9）2015, Spring Cloud Netflix 正式发布 1.0 版本. 成为微服务架构的首选
10）2018 年 10 月 31 日 Spring Cloud Alibaba 宣布正式开源

2. 微服务架构的先驱

• Martin Fowler (上图右 1)，写了很多经典的书：企业应用架构模式重构等、敏捷宣言 17 发起人之一，目前一直活跃软件架构领域。他是在技术大会上公开进行与演讲、推广，为领域做出了很大贡献
• James Lewis 詹姆斯里维斯（上图下方）微服务架构发明人，在 Thoughtworks 主要负责服务架构宣传与咨询。
• Adrian Cockcroft 阿德里安（上图左一）为麦飞的技术总监，将理论和实践结合的先驱，基于 Java 框架做出了一套自研微服务解决方案，并且开源给社区。

微服务架构 Microservice 的优缺点

1. 微服务 e Microservice 优点

1）开发简单；
2）技术栈灵活；
3）协议简单；
4）服务独立无依赖；
5）独立按需扩展；
6）可用性高；
7）高伸缩性；
8）易于维护单一服务。

1 ） 微服务特点一：快速响应需求变化

从早期的互联网公司开始，快速过渡到现在的移动互联网公司，都在大量使用微服务架构，包括大家熟悉的淘宝、微博、微信、抖音等平台，都是很典型的代表。微服务架构很重要的特点就是： 快速响应需求变化，业务迭代非常快，每月甚至每周都会有大量的改版信息。

微服务本质上是小微程序，相比较来说，很重要的特点是拆分概念。微服务首先是拆分，把大的拆成小的，把整体拆成部分。每个部分单独开发迭代，是很重要的优势，在中国书画里面叫船小好调头。

微服务优点是拆完以后更灵活，各个子系统可以 独立开发、 独立测试、 独立部署、独立进程，最后在集成。

2） 特点二：敏捷开发、敏捷运维 DevOps

微服务架构的优点，本质上就是拆完以后更好开发。通常是 HTTP 协议，能信使用语言中立协议等，优点和缺点是相对某个技术架构的，不是绝对的。、

总结如下：
1）易于替换；
2）独立部署；
3）专注某个任务；
4）高度解耦；
5）基于功能进行组织：商品、支付、评论、机票、新闻、酒店、游戏等；
6）服务可以使用不同的语言、系统、平台；
7）通信使用语言中立的协议；
8）通常是 http；
9）独立技术栈；
10）易于测试。

巨型服务 VS 微服务

早期的单体巨型服务，分层架构，适用于比较稳定的系统，比如银行系统，现在还在使用。随着业务的发展变化，可以更换新的架构。微服务架构非常灵活，合适迭代发展快的项目，比如当下流行的电商业务。

2. 微服务 Microservice 缺点

微服务不是银弹：

微服务并不适合所有的场景，因为一旦拆开，通信成本就会上升，架构复杂度会上升，开发人员需要更多，集成测试、部署都会变得更复杂，所以技术选型一定要慎重。

微服务的缺点：

1）架构复杂；
2）多服务运维难度；
3）系统部署依赖；
4）服务间通信成本；
5）数据一致性；
6）系统集成测试；
7）重复工作；
8）性能监控。

微服务架构 Microservice 的典型应用场景

一、 微服务架构 4 4 大互联网公司案例

目前打开苹果或者种安卓等机器手首页上的应用，基本上都是微服务架构，几个比较典型的代表像淘宝、支付宝、微信、微博、京东等等都是典型的微服务架构。

微服务架构的案例如电商类的、微博类的、微信类、社交类的、支付类的、直播类的、游戏类、互联网类的、广告类到处都是。

这背后反映了架构的拆分，本质上反映的是业务的一个拆分，业务的快速发展技术也一定要快速发展，技术架构快速迭代，才能去适应业务快速发展的模型，这是它的本质的特征。

2. 微服务架构经典案例

几个典型的架构做为参考，如淘宝的微服务架构，微服务架构的拆分原则，以及框架选型。

3. 微服务与电商架构

电商类以淘宝为例，是对重度使用 Java 技术架构，严格来说阿里对 Java 的整个体系的发展是做出了突出的贡献，有很多实践落地的方案，包括自己开发的一些科研框架贡献，如现在看到淘宝的账户，后面衍生出来支付的平台，剥离出支付宝，又发展成一个庞大的系统平台，里面有各种子系统，各种子业务如余额宝也是一个独立的微服务架构。

一般拆分以后维护后期，可能还要做集群，考虑高可用高并发的问题可能会做集群。这是里面体现了一个弹性伸缩的概念，如支付宝淘宝，包支付宝淘宝可以共享账号，淘宝有个概念是打通所有的平台，这些可以叫单点登录。

淘宝账号服务是独立出来的，独立进行发展，账号提供全局的统一的验证服务，可能支付宝更稍微复杂一点，有信用的接口，个人的支付的信用的大数据都在里面。

4. 微服务与物联网 IOT 架构

物联网现在是火爆发展，各种监控设备，包括车载的设备都是物联网的体现，移动导航的一些设备，物联网在车载设备中现在用的比较多的方向，如特斯拉、各种电动汽车大量的使用车载雷达、还有摄像头，这都是互联网，楼宇监控，尤其我交通的监控，公安的人脸识别的网络都是物联网的典型的应用，做这种解决方案很容易，尤其是汽车车载物联网系统，像特斯拉，都很适合微服务架构，还有飞机也有定位导航的设备，大楼火灾、温度、光照、湿度都有。

5. 微服务与游戏 IOT 架构

游戏平台更多，腾讯做游戏在国内是最大的游戏厂商，如王者荣耀、穿越火线等等一系列游戏，微信里面可以提供入口，也是典型的微服务架构。因为账号登录其中任何一个游戏平台，都是腾讯的微信账号，这些数据独立统一以后，方便用户去访问不同的游戏平台，快速进行推广上线，用户的体验。

微服务架构 Microservice 的经典协议

一、微服务常用的通信模式

• 微服务的消息通信模式

消息交换的模式有很多种，使用较多的是同步消息的交互模式，典型特征是发送完消息后会等待一个结果，浏览器发送一个网页请求后，会等待网页返回，中间存在请求应答的过程，这就属于同步请求的模式。

异步请求模式的常见场景是消息推送，发送完某个消息后，这个消息并不会立即到达，可能会经过一定延迟才到达接收方。异步模式的优点是并发或吞吐量较高；缺点是无法保证消息的实时性。

目前在分布式架构上，同步与异步相结合的消息交换场景也很常见。协议上绝大部分都是同步模式，个别支持异步，例如邮件协议或者消息协议。

二、经典的 RPC 协议

下图是在分布系统中常用的一些 RPC 协议。RPC 本身是远程过程调用，主要解决远程的通信问题，而不仅是封装原始的数据通信协议与网络协议。

在此基础上，需要借助某些框架语言来实现功能的交互。例如，希望客户端通过调用服务器端的某个订单或者加密的功能，实现远程的功能调用。

上图是在分布系统中常用的一些 RPC 协议。RPC 本身是远程过程调用，主要解决远程的通信问题，而不仅是封装原始的数据通信协议与网络协议。

这是通过网络来暴露自己代码功能较早的一种方式。RPC 协议非常多，不仅是REST API,APP 协议暴露接口，前端分裂架构基本上也都是 API 加前端、小程序、APP、PC 网页等这种模式，是在移动互联网时代用得较多的架构。

Rest API 基本上走的是 APP 协议，一般是接收数据格式。在这个领域里面，RPC概念在 native 本身也支持分布式通信框架。但是相对来说，在大规模分布式集群治理领域，阿里的 Dubbo 设计非常优秀，不断迭代，表现优异。

数据库 JDBC 属于分布式通信解决方案之一，但通信协议是 GDB 框架定义，专有的协议格式，支持引入中间链、消息队列等，使用不同的协议进行通信。

三、微服务常用的通信协议

目前，微服务以 Spring Cloud 开发为代表，选取的是 Rest 通信接口格式，后续的微服框架可能更多，有些微服务支持更多的协议和数据格式。目前主流的是 HTTP，属于同步消息通信模式，H5 走 websocket。

当下的移动互联网时代大部分追求轻量级接口，目前的框架如 Rest API、Java、Go 还是 node，都非常方便，可以直接在 APP 协议站基础上进行扩展。

微服务架构 Microservice 的开发框架

Spring Cloud 是出现的时间比较早框架，并且它的生态也是最完善的，包括 Java 本身 Spring Cloud 也在不断迭代，也出现新的贡献微服务架构的框架。

一、微服务架构的开发框架

1）Spring Cloud：最早最成熟，Java 开源微服务框架方案
2）Dubbo : 阿里巴巴开源 Java 服务治理框架
3）Spring Cloud Alibaba 阿里开源 Java 微服务框架方案
4）SOFA：蚂蚁金服开源 Java 金融微服务框架方案
5）Go Micro：Go 语言开源微服务框架
6）Seneca Microservices ，Node.js 微服务框架
7）KumuluzEE：Java 的微服务框架
8）Enduro/X： C/C++/Go

目前 Spring Cloud 是最早的开源的版本，主要几个核心框架是netflix美国的视频网站公司贡献的。他们把自己公司内部实践的开发的微服务的解决方案框架贡献给了社区。它主要也是想体现云计算的这样的时代的特征，这个核心框架基本上都是用Java 来进行编写的，而且也现经过这么多年的发展，目前在全球范围内来看的，它是最成熟的一套生态。像国内的阿里巴巴、蚂蚁金服、京东、微博、拼多多、美团等新崛起的互联网公司都在使用 Spring Cloud 微服务框架体系。

除了 Dubbo 以外，内部还有 hsf 框架，早期是解决大规模服务治理的问题，后面进行在内部不断优化协议、性能。Dubbo 在开源以后，国内有很多互联网公司都在用，影响也比较大。作为微服务架构设计的选型的话，Dubbo 不会作为首选，但是 Dubbo 是一个有效的补充。

并不是所有的场景，用 HTTP 协议是最优秀的，后续 Spring Cloud 的版本或者其他的微服务框架，会在协议，通讯协议，数据格式类型尝试做一些优化，因为阿里打包开源一些列的微服务给 Spring Cloud 作为贡献的一部分。

外国就是netflix，国内就是阿里巴巴作为最大的贡献者。像蚂蚁金服的 SOFA、GO 语言的 Go Micro 都是仿制 SpringCloud。Java 并不是强在语法，开发工具都不是最好的，强在框架和生态，升级模式。新的设计模式的书都是率先在 Java 实践出来的。

二、微服务开发框架对比

Spring Cloud 是出现最早的，最成熟最完善的一套微服务架构综合解决方案。它协议上 HTTP 为主，国内外公司大部分都在使用。阿里的 Dubbo 也开源了，并向微服务进发，开始也支持其他的框架的集成。虽然 Go 语言和C++都有微服务框架，但是出现的比较晚，生态并不是太完善。作为微服务架构师来说，Spring Cloud 和 Dubbo 体系最完善。

三、Spring Cloud 微服务架构生态最完善、最成熟

Spring Cloud 本身成长于 Java Spring 整个平台体系中来，之前 JavaSpring 积累的所有生态工具都可以拿过使用。可快速开发、集成、安全设计模块工具、容器的工具可直接使用。加上国内互联网公带头扩展实践落地。Spring Cloud 是架构选型风险成本最低的。Spring Boot、Spring Data 都在协助 Spring Cloud 维护开发，拥有一套很大，并完善生态。

四、Spring Cloud 微服务架构

框架它是在不断迭代不断发展的，微服务开发的话不仅仅是 Spring VC 或者Spring Boot，还有各种工具 ，也可以来开发这种微服务，实现各种需求：网关、熔断、注射、包括数据库交互、前端对应 APP、小程序。微服务拆分好处在于走小块零的路线，也可以单独进行部署。比如：有的系统订单服务支付服务用的比较多，比如淘宝单独做大规模集群，客服投诉服务使用就比较少，拆分之后占用的服务器少。拆分的原因取决业务需求，存在差异之后，可以分开处理问题。

每个环节解决不同的问题，无论是注册、发现、部署、网关都有自己的对应解决方案框架。目前的话就是选型的话，首推是 Spring Cloud，因为是一个成熟完善的生态。在技术选型的时候还要尊重业务需求、技术落地、风险问题、考虑公司研发成本等综合考虑，不单单是自己语言的喜好的问题。

微服务架构 Microservice 的设计策略

一、 微服务 Microservice 的设计原则

微服务架构本身也属于分布式架构，只不过它是更复杂的分布式架构。我们在讲微服务概念的时候，咱们提到过微服务实际它是诞生于 SoA 时代所以它还具备 SoA 架构的一些特点。我们所有的架构设计有很重要的一个原则：

需求第一：一定要以需求为出发点。所有的架构好与坏一定是相对的，相对他处的一个需求背景。

单一职责：我们的服务尽量是体现单一职责的思想，粒度不是越细越好，也不是越粗越好。

协议统一：还有尽量去统一协议，不包括不得已的话，我们不引入其他协议像我们一般微服务的话，咱们讲现在目前的协议主要是 rest 有可能会比如说有可能你会引入消费者的协议，或者引入其他的这种通讯协议，当然在我们说都是基于实际的需求

独立开发：独立开发一般咱们这里面提到的我们说的是模块拆分以后开发人员一般是独立我们按照模块进行拆分，然后每个人负责一块，每个人熟悉一块代码和逻辑业务逻辑这样的话开发时间都会相对来说高很多

独立部署：独立部署这也是微服架构的很重要的一个原则，咱们讲了微服务架构拆分以后又会出现可能很多程序很多进程，而且每一个模块不是所有的都更新只需要迭代我那一块就行了，就是体现了我们说叫分而治之的这样一个思想。

二、 微服务 Microservice 的拆分原则

1. 按照业务模块拆分
2. DDD 思路可以借鉴，不能照搬
3. 单一职责 e Single Responsibility
4. 电商架构设计：

场景它本身就像个生态一样，它里面接入的功能模块多，这里面天生适合和足够庞大的基础上适合分人制快速迭代。微服务架构，新的业务诞生早期可能只有两三台服务器，后面的话做起来可能上千台服务器。包括游戏也一样前端很多平台是属于导游的模式，加入一个模块进来，这个平台作为一个入口。拆分原则一般的话我们是基于业务进行拆分，或者你也可以说是 DDD.

三、微服务 Microservice 设计的关注点

微服务架构设计的时候，大家关注并发性，可用性、安全性、密等性、重用性。

服务隔离，各个服务之间互不影响，高并发了也不要影响，扩容也不要影响。

四、微服务 Microservice 设计的五大考量

服务架构里面在做事物的话是比较难的，所以要注意一个数据一致性问题。

微服务架构 Microservice 的经典设计模式

一、微服务架构设计模式

1）业务分解：DDD 模式
2）DataBase PerService 每数据库单服务
3）API Gateway pattern API 网关模式
4）Client-side Discovery 和 Server-side Discovery 模式
5）Messaging 和 Remote Procedure Invocation 模式
6）SingleServiceper Host 和 Multiple Services per Host 模式 7
7）AOP: Microservice chassis pattern
8）Externalized configuration
9）Service Component Test 和 Service Integration Contract Test
10）Circuit Breaker 断路器模式
11）Access Token 访问令牌模式
12）观察者模式:Distributed tracing、 Health check API
13）UI 模式:MVC、MVPMVVM 模式

微服务架构中的经典的设计模式，一般提到微服务会认为微服务架构指的是一种架构，实际上微服务架构本身涵盖几十种设计模式，可能后续还有更多的设计模式。

服务拆分的一般借鉴 DDD 模式，但不是照搬，不能完全等同。

二、微服务设计模式分类

应用架构模式：
单点登录
注册发现
熔断限流
断路器
网关模式
消息补偿模式
令牌模式

数据库:

分库 Single Service
共库多 Service
多库同步
事务性补偿

日志追踪模式:

观察者模式 patterns
Log aggregation
Application metrics
Audit logging
Distributed tracing
Exception tracking
Health check API
Log deployments and changes
分布式链路追踪模式

UI 模式:

MVC
MVP
MVVM
Server-side page fragment composition
Client-side Ul composition