1、Spring Cloud - 微服务简介

前言：

业界大牛马丁.福勒（Martin Fowler） 这样描述微服务：

论文网址:https://martinfowler.com/articles/microservices.html

就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style）

但通常而言， 微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，

每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。

服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。

每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，

可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

 

 （Dubbo是基于RPC调用）

 （SpringCloud是基于Http的RESTFUL API）

技术维度理解：

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，

彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事。

 

 

从技术角度看就是一种小而独立的处理过程，类似进程概念，

能够自行单独启动或销毁，拥有自己独立的数据库。

微服务与微服务架构

微服务

强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用,

狭意的看,可以看作Eclipse里面的一个个微服务工程/或者Module

  

微服务架构

微服务架构是⼀种架构模式，它提倡将单⼀应⽤程序划分成⼀组⼩的服务，服务之间互相协调、互相配合，为⽤户提供最终价值。

每个服务运⾏在其独⽴的进程中，服务与服务间采⽤轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。

每个服务都围绕着具体业务进⾏构建，并且能够被独⽴的部署到⽣产环境、类⽣产环境等。

另外，应当尽量避免统⼀的、集中式的服务管理机制，对具体的⼀个服务⽽⾔，应根据业务上下⽂，选择合适的语⾔、⼯具对其进⾏构建。

1.1、单体架构及其存在的不足

1.1.1 单体架构简介

经典的 3层模型，即表示层、业务逻辑层和数据访问层。

---表示层： 用于直接和用户交互，也称为交互层，通常是网页、 UI等。

---业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展砚给用户。

---数据访问层 ：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。

典型的 J2EE 工程，它是将表示层的 JSP 、业务逻辑层的

Service Controller 和数据访问层的 Dao ，打成 war 包，

部署在 Tomcat、Jetty 或者其他 Servlet容器中运行。

1.1.2 单体架构存在的不足

--业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性

   下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。

--随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限

--测试的难度越来越大，单体应用的业务都在同 个程序中，随着业务的扩张、复杂度

   的增加，单体应用修改业务或者增加业务或许会给其他业务带来 定的影响，导致测

   试难度增加。

1.1.3 单体架构使用服务器集群及存在的不足

随着业务的发展，大多数公司会将单体应用进行集群部署，井增加负载均衡服务器。

 

还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，

以应对用户 的增加而带来的高并发访问量。

---系统仍然为单体应用，大量的业务 必然会有大量的代码，代码的可读性和可维护性依然很差。

---面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表

---持续交付能力差，业务越复杂，代码越 ，修改代码和添加代码所 的时间越长。新人熟悉代码的时间 、成本高。

 

在应用初期，单体应用从成本、开发时间和运维等方面都有明显的优势。

随着业务盐和用户聋的增加，它所暴露出来的缺点也显而易见。

单体架构己经不能满足复杂的业务和海茧的用户系统，改变单体架构势在必行。

1.2、微服务

微服务是最近 两年才出现的新名词，它在各大技术社区、博客、论坛和新闻报道中经常

被提及，是程序员和 架构师经常讨论的话题。

1.2.1 什么是微服务

“微服务”最初是由 Martin Fowler 在2014 年写的 1篇文章《MicroServices 》中提出来的。

关于 Martin Fowler 的介绍，维基百科上是这样描述的：

---按业务划分为一个独立运行的程序，即服务单元。

---服务之间通过 HTTP 协议相互通信。

---自动化部署。

---可以用不同的编程语言。

---可以用不同的存储技术。

---服务集中化管理。

---微服务是 个分布式系统。

1. 微服务单元按业务来划分

可以从以下3个方面来界定： 

1、是根据代码量来定义，根据代码的多少来判断程序的大小： 

2、是根据开发时间的长短来判断：

3、 是根据业务的大小来划分。

2. 微服务通过 HTTP 来互相通信

按照业务划分的微服务单元独立部署 并运行在各自的进程中。微服务单元之间的通信方

方式一般倾向于使用 HTTP 这种简单的通信机制，更多的时候是使用 RESTfulAPI 。

 

这种接受请求、处理业务逻辑、返回数据的 HTTP 模式非常高效，并且这种通通信机制与平台和语言无关。

3. 微服务的数据库独立

在单体架构中，所有的业务都共用 个数据库。

 

微服务的 个特点就是按业务划分服务，服务与服务之间无稠合，就连数据库也是独立的。

一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。

 

随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供 API接口相互调用

还有 个好处是数据库独立，单业务的数据盆少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。

 

 

另外，随着存储技术的发展，数据库的存储方式不再仅仅是关系型数据库，非关系数据库

的应用也非常广泛，例如 MongDB， Redis ，它们有着良好的读写性能，因此越来越受欢迎

4. 微服务的自动化部署

在微服务架构中，系统会被拆分为若干个微服务 每个微服务又是 个独立的应用程序

单体架构的应用程序只需要部署 次，而微服务架构有多少个服务就需要部署多少。

 

如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度

划分得越细，微服务的数量就越多，这时需要更稳定的部署机制

 

随着技术的发展，尤其是Docker 容器技术的推进，以及自动化部署工具

（例如开源组件 Jenkins ）的出现，自动化部署变得越来越简单。

 

5. 服务集中化管理

微服务系统是按业务单元来划分服务的 ，服务数量越多 管理起来就越复杂，因此微服务

必须使用集中化管理。目前流行的微服务框架中，例如 Spring Cloud 采用 Eureka 来注册服务

和发现服务，另外， Zookeeper、Consul 等都是非常优秀的服务集中化管理框架。

 

6. 分布式架构

分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。

当分布式系统对外提供服务时，用户是毫不知情的，还以为是 台服务器在提供服务。

 

分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在计算机上完成。

 

分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务

器可以部署不同的机房和不同的地区。

 

分布式系统的应用都是集群化部署 会给数据 致性带来困难。分布式系统中的服

务通信依赖于网络 网络不好，必然会对分布式系统带来很大的影响。

 

在分布式系统中，服务之间相互依赖，如果 个服务出现了故障或者是网络延迟，在高并发

的情况下，会导致线程阻，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用 。

 

由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类

事件的发生，分布式系统必然要采取相应的措施，例如“熔断机制”。

 

7. 熔断机制

为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。在用 Spring Cloud构

建的微服务系统中，采用了熔断器（即 Hystrix组件的 Circuit Breaker ）去做熔断。

1.2.2 微服务的优势

相对于单体服务来说，微服务具有很多的优势，主要体现在以下方面：

 

1、将 1个复杂的业务分解成若干小的业务，每个业务拆分成 个服务，服务的边界明

确，将复杂的问题简单 。服务按照业务拆分 编码也是按照业务来拆分，代码的可读性和可

扩展性增加。新人加入团队，不需要了解所有的业务代码，只需要了解他所接管的服务的代码，

新人学习时间成本减少。

 

2、由于微服务系统是分布式系统，服务与服务之间没有任何的祸合 随着业务的增加，

可以根据业务再拆分服务 具有极强的横向扩展能力。随着应用的用户量的增加，井发量增加，

可以将微服务集群化部署，从而增加系统的负载能力 简而 之，微服务系统的微服务单元

有很强的横向扩展能力

 

3、服务与服务之问通过 HTTP 网络通信协议来通信，单个微服务内部高度祸合，服务与

服务之间完全独立，无调合。这使得微服务可以采用任何的开发语言和技术来实现。开发人员

不再被强迫使用公司以前的技术或者已经过时的技术，而是可 自由选择最适合业务场景的或

者最适合自己的开发语言和技术，提高开发效率、降低开发成本。

 

4、如果是 个单体的应用，由于业务的复杂性、代码的祸合性，以及可能存在的历史问

题。在重写 个单体应用时，要求重写的应用的人员了解所有的业务，所以重写单体应用是非

常困难的，并且重写风险也较高。如果是微服务系统，由于微服务系统是按照业务的进行拆分

的，并且有坚实的服务边界，所以重写某个服务就相当于重写某 个业务的代码，非常简单。

 

5、微服务的每个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和

部署对其他服务没有影响。试想，假设 个应用只有 个简单的修改，如果是单体架构，需要

测试和部署整个应用；而如果采用微服务架构，只需要测试并部署被修改的那个服务，这就大

大减少了测试和部署的时间。

 

6、微服务在 AP 理论中采用的是 AP 架构，即具有高可用和分区容错的特点 。高可用

主要体现在系统7 x 24 小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系

统的负载能力。另外，分区容错也使得系统更加健壮。

优点

每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求

开发简单、开发效率提高，一个服务可能就是专一的只干一件事。

微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。

微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

微服务能使用不同的语言开发。

易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。

微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

微服务允许你利用融合最新技术。

微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。

每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

1.3、微服务的不足

---微服务的复杂度

---分布式事务。

---服务的划分。

---服务的部署。

 

1.3.1、微服务的复杂度

构建 个微服务系统并不是 件容易的事，微服务系统是分布式系统，构建的复杂度远远

超过单体系统，开发人员需要付出 定的学习成本去掌握更多 的架构知识和框架知识。服务与

服务之间通过 HTTP 协议或者消息传递机制通信，开发者需要选出最佳的通信机制，并解决网

络服务较差时带来的风险。

 

1.3.2 分布式事务

微服务架构所设计的系统是分布式系统。分布式系统有一个著名的 CAP 理论，即同

时满足“ 致性”“可用性”和“分区容错”是 件不可能的事。 

 

CAP 理论是由 Eric Brewer2000年 PODC 会议上提出的 ，该理论在两年后被证明成立。 

CAP 理论告诉架构师不要妄想设计出同时满足三者的系统 ，应该有所取舍，设计出适合业务的系统。

1.3.3 服务的划分

对于微服务的拆分原则， Martin Fowler 给出的建议 ：服务是可以被替换和更新的。

也就是服务和服务之间无祸合，任何 个服务都可以被替换，服务有自己严格的边界。

 

当然这个原则很抽象，根据具体的业务场景来拆分服务 需要依靠团队人员对业务的

熟悉程度和理解，程度，并考虑与己有架构的冲突、业务的扩展性、开发的风险和未来业务

的发展等诸多因素。

 

领域驱动设计是 个全新的概念，也是 1个比较理想的微服务拆分的理念。

领域驱动设计通过代码和数据分析找到合理的切分点，并通过数据分析来判断服务的划分边

界和划分粒度目前来说，在中罔几乎没有公司去落地领域驱动设计这个理念，随着微服务的

发展，这 一理念在以后有可能会落地。

 

1.3.4 服务的部署

一个简单的单体系统可能只需要将程序集群部署井配置负载均衡服务器即可，而部署

复杂的微服务架构的系统就复杂得多。

因为每一个微服务可能还涉及比较底层的组件，例如数据库、消息中间件等。

 

例如使用 PaaS 服务、使用Docker 编排等。这就是人们往往提到微服务，就会想到

Docker DevOps 原因。其中，微服务是核心： Docker 为容器技术，是微服务最佳

部署的容器： DevOps 是一种部署手段或理念 。

缺点

开发人员要处理分布式系统的复杂性

多服务运维难度，随着服务的增加，运维的压力也在增大

系统部署依赖

服务间通信成本

数据一致性

系统集成测试

性能监控……

1.4、微服务和 SOI 的关系

 

SOA 即面向服务的架构，这种架构在20年前就已经被提出了。

SOA 往往与企业服务总线(ESB ）联系在 起，主要原因在于 SOA 的实施思路是根据 ESB 模式

来整合集成大量单一庞大的系统，这是 SOA 主要的落地方式 然而， SOA 在过去 20 年并没有

取得成功。在谈到微服务时，人们很容易联想到它是 个面向服务的架构。的确，微服务的概念

提出者 Martin Fowler没有否认这一层关系。

 

微服务相对于和 ESB 联系在 起的 SOA 显然轻便敏捷得 ，微服务将复杂的业务组件化，

实际也是 种面向服务思想的体现。对于微服务来说，它是 SOA 的一种实现，但是它比 ESB

实现的 SOA 更加轻便、敏捷和简单。