微服务架构学习（一）

一、什么是微服务

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
最早微服务的概念源于2014年3月Martin Fowler所写的一篇文章 ——“Microservices”

二、发展历程

架构设计漫步：从单体架构——>SOA——>微服务

1、单体架构

Web应用程序发展的早期，大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。其他语言(Ruby，Python或者C++)写的程序也有类似的问题。

假设你正在构建一个在线商店系统：客户下订单、核对清单和信用卡额度，并将货物运输给客户。很快，你们团队一定能构造出如下图所示的系统。

这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构（也叫：巨石型应用）。

优势：单体架构适用于不复杂的应用。IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。

劣势：对于大规模的复杂应用，单体架构应用会显得特别笨重：要修改一个地方就要将整个应用全部部署;编译时间过长;回归测试周期过长;开发效率降低等。另外，单体架构不利于更新技术框架，除非你愿意将系统全部重写。

2、单体架构的拆分

详细一个网站在业务大规模爬升时会发生什么事情?
并发度不够?加web服务器。
数据库压力过大?买更大更贵的数据库。
数据库太贵了?将一个表的数据分开存储，俗称“分库分表”。

(1)x轴，水平复制，即在负载均衡服务器后增加多个web服务器;

(2)z轴扩展，是对数据库的扩展，即分库分表(分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过hash放在不同的数据库服务器上);

(3)y轴扩展，是功能分解，将不同职能的模块分成不同的服务。从y轴这个方向扩展，才能将巨型应用分解为一组不同的服务，例如订单管理中心、客户信息管理中心、商品管理中心等等。

3、SOA架构

SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范 ;一步解决的核心问题是【有序】

系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

ESB(企业服务总线)

ESB服务总线是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。
简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

4、微服务架构

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
最早微服务的概念源于2014年3月Martin Fowler所写的一篇文章 ——“Microservices”

微服务架构的思考是从与整体应用对比而产生的。

其中，对应用组件封装的方式是整体架构与微服务架构的主要差异.
微服务架构将相关联的业务逻辑及数据放在一起形成独立的边界，目的是能在不影响其他应用组件(微服务)的情况下更快地交付并推出市场。

1. 通过服务实现组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
2. 围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。
3. 去中心化的治理和数据管理：
   治理：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
   数据管理：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
4. 智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
5. 基础设施自动化（Devops、自动化部署）
   Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包.
   而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多，不集中管理就无法DevOps）。

微服务结构图

微服务API网关

微服务架构仍然需要对微服务架构进行统一管理——API网关，在微服务架构架构下都是标准的Http Rest接口和AMQP消息接口，没有传统的服务适配和协议转换，同时对于服务的编排这种重的能力也不再需要。那么更多的将体现在对服务的管理能力上。这种管理能力包括了服务的统一注册和发现，服务安全，服务集群和路由，服务限流，日志等能力上。

三、SOA与微服务架构的区别与联系

首先SOA和微服务架构一个层面的东西，是架构风格和方法。
而对于ESB和微服务网关是一个层面的东西，是实现工具或组件。

1、SOA与微服务架构的区别与联系

微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，强调了两个重点，一个是找到离散，自治，粗粒度和可重用的服务能力，其次是服务本身可以灵活的组合和编排适应业务变化。

2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，强调单体的各个微服务模块能够独立、自治并在独立的进程中运行，同时微服务之间能够通过轻量的服务接口进行交互和协同。

3.SOA强调粗粒度，而微服务架构不会过分强调，由于模块划分细了，本身想粗粒度更加难。
SOA强调可复用，而服务架构不太强调，要考虑到在分层架构模型中UI到服务层也需要全部走服务接口

由于在微服务架构在代码中完成了服务组合的编排，在底层微服务模块基础上最好能够有提供领域服务能力的模块来实现服务的组合和组装。因此领域服务设计思想在微服务架构中有重要的地位。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

误区：因此绝对不能简单的将微服务架构理解为简单了做到组件化和数据库拆分，使用了Http Rest接口，或者说使用了类似Spring Cloud等微服务框架就是微服务架构。

2、ESB和微服务API网关

ESB服务总线可以理解为将传统的单点集成转化为总线式集成的核心部件，通过将所有的服务注册和接入，来实现对所有服务运行的管理和监控，在这个过程中提供了服务注册，适配器，协议转换，消息格式转换，消息集成，数据映射，简单服务编排，安全认证，日志，流控等多种能力。

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

微服务网关的能力：服务注册和发现，微服务网关，服务限流和容错能力

微服务网关 = 传统ESB + 去掉了复杂服务适配和协议转换 +去掉了服务编排 + 提升了限流容错能力

3、主要区别

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队，快速更新迭代

四、参考文献

1.Microservices：https://martinfowler.com/articles/microservices.html

2.什么是微服务：https://blog.csdn.net/fly_zhyu/article/details/76408158

3.SOA架构与微服务架构的区别：https://blog.csdn.net/zpoison/article/details/80729052

4.架构设计漫步：从单体架构、SOA到微服务-架构：http://www.uml.org.cn/zjjs/201708083.asp

5.SOA和微服务架构的区别_百度知道：https://zhidao.baidu.com/question/1899225333752310100.html

6.从SOA到微服务架构：http://blog.sina.com.cn/s/blog_493a84550102wq50.html

7.粗粒度和细粒度的区别：https://blog.csdn.net/u013063153/article/details/74518644

8.开发运维一体化(DevOps)：http://blog.tianya.cn/post-7529426-130823543-1.shtml

9.对象请求代理：https://baike.so.com/doc/4920871-5139961.html

10.负载均衡基础知识：https://www.cnblogs.com/danbing/p/7459224.html

11.在微服务架构中，我们还需要ESB吗?：https://blog.csdn.net/gongwx/article/details/52420862

12.微服务结构理解图：https://blog.csdn.net/bcqtt/article/details/79649296