不胖不“威”的微服务架构

Posted 2021-04-14 顶级技术合伙人

        “我看你骨骼精奇，是万中无一的武学奇才。”其实做什么都讲究个天分的，哪怕做软件。一个软件的架构基础就决定了他的未来，哪个系统弱不禁风，哪个系统资质平庸，哪个系统反复重构，哪个系统费时费钱，哪个系统扩展性好，哪个系统威力强大。

   从单体架构、SOA到微服务微服务架构。单体架构属于十几年前比较常用的技术。Monolithic（单体式开发），所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。单体架构中web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，其他语言(Ruby，Python或者C++)写的程序类似。

单体架构优点：

1，开发简单，容易测试。在本地就可以启动完整的系统、容易部署，直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。

2，基本不会重复开发

3，功能都在本地，没有分布式的管理和调用

单体架构缺点：

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断。

2、维护难：代码功功能耦合在一起，一团混乱的代码，新人刚开始不知道从何下手。

3、耗时长：构建时间长，任何小修改都要重构编译整个项目，耗时耗力耗钱。

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉

5、扩展性不够：无法满足高并发下的业务需求

6，太笨重：对于大规模的复杂应用，单体架构应用会显得特别笨重：要修改一个地方就要将整个应用全部部署，也不利于更新技术框架，需要将系统全部重构重写，代价太高。

常见的系统架构遵循的三个标准和业务驱动力：

1、提高敏捷性：及时响应业务需求，促进企业发展

2、提升用户体验：提升用户体验，减少用户流失

3、降低成本：降低增加产品、客户或业务方案的成本

基于微服务架构的设计目的：有效的拆分应用，实现敏捷开发和部署

单体架构的拆分：

这张图从三个维度概括了一个系统的扩展过程：

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

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

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

SOA与微服务：

SOA:服务导向式架构（SOA）是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件。一般来说，每个组件会从始至终执行一块完整的业务逻辑，通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的，但这并非SOA架构模式的要求。

微服务：是一种架构设计模式。在微服务架构中，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用。每个组件都被称为微服务，而每个微服务都在整体架构中执行着单独的任务，或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，以执行较大应用需要完成的具体任务；系统还为任务执行——比如搜索或显示图片任务，或者其他可能需要多次执行的任务提供了统一的解决处理方式，并限制应用内不同地方生成或维护相同功能的多个版本。

1）. 负责单个功能

2）. 单独部署

3）. 包含一个或多个进程

4）. 拥有自己的数据存储

5）. 一支小团队就能维护几个微服务

6）. 可替换的

相对于SOA的区别：

SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。SOA喜欢重用，微服务喜欢重写。SOA喜欢水平服务，微服务喜欢垂直服务。SOA喜欢自上而下，微服务喜欢自下而上。微服务不在强调传统SOA架构里比较重的ESB企业服务总线，同时微服务真正实现单个业务系统内部真正的组件化。

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

微服务（Microservice）这个概念出现在2012年，2014年开始受到各方的关注，2015年可算作微服务的元年。它是互联网技术发展的必然结果，作为加快Web和移动应用程序开发进程的一种方法，它倡导将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。虽然微服务架构没有公认的技术标准和规范，但业界已经有一些很有影响力的微服务架构框架，例如Dubbo和Spring Cloud。

我们为什么采用微服务呢？"让我们的系统尽可能快地响应变化" - Rebecca Parson 让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话，那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化，在同期出现了诸多轻量级开发方法（诸如 XP、Scrum）；2001年敏捷宣言诞生，之后又出现了精益、看板等新的管理方式。如果说，这些是为了尽快的响应变化，在软件开发流程和实践方面提出的解决方案，那么微服务架构就是在软件技术和架构层面提出的应对之道。

微服务的具体特征官方的定义：

1、一些列的独立的服务共同组成系统

2、单独部署，跑在自己的进程中

3、每个服务为独立的业务开发

4、分布式管理

5、非常强调隔离性

标准参考：

1、分布式服务组成的系统

2、按照业务，而不是技术来划分组织

3、做有生命的产品而不是项目

4、强服务个体和弱通信（Smart endpoints and dumb pipes ）

5、自动化运维（ DevOps）

6、高度容错性

7、快速演化和迭代

要应用微服务，需要解决这几个问题：

1、客户端如何访问这些服务

2、每个服务之间如何通信

3、如此多的服务，如何实现？服务挂了，如何解决？（备份方案，应急处理机制）

常见的设计模式和应用

有一个图非常好的总结微服务架构需要考虑的问题，包括：

1、API Gateway

2、服务间调用

3、服务发现

4、服务容错

5、服务部署

6、数据调用

六种常见的微服务架构设计模式：

1、聚合器微服务设计模式

这是一种最常见也最简单的设计模式：

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2、代理微服务设计模式

这是聚合模式的一个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。如下图所示：

3、链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应，在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。如下图所示：

4、分支微服务设计模式

这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：

5、数据共享微服务设计模式

自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。

因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。如下图所示：

6、异步消息传递微服务设计模式

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示：

Dubbo微服务框架:Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。Remoting: 网络通信框架，实现了 sync-over-async 和request-response 消息机制.RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能Registry: 服务目录框架用于服务的注册和服务事件发布和订阅。

·        Dubbo 核心部件（如图）:

·        Provider：暴露服务的提供方，可以通过jar或者容器的方式启动服务

·        Consumer：调用远程服务的服务消费方。

·        Registry：服务注册中心和发现中心。

·        Monitor：统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示，目前只有一个简单版本）

·        Container：服务运行的容器。

Spring Clould微服务框架,Spring Cloud则是一套微服务开发和治理框架，包含了微服务运行的功能，为开发者提供了一些快速构建分布式系统的云应用开发工具。它基于SpringBoot的开发便利性，简化了分布式系统基础设施的开发。如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

spring cloud子项目包括：

Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。

Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与SpringCloud Config联合实现热部署。

Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。

Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。

Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。

Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。

Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。

Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。

Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。

Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。

Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

pring Boot让我们的Spring应用变的更轻量化。比如：你可以仅仅依靠一个Java类来运行一个Spring引用。你也可以打包你的应用为jar并通过使用java -jar来运行你的SpringWeb应用。

微服务对我们的思考，更多的是思维上的转变。

关于微服务的几点设计出发点：

1、应用程序的核心是业务逻辑，按照业务或客户需求组织资源（这是最难的）

2、做有生命的产品，而不是项目

3、头狼战队，全栈化

4、后台服务贯彻Single Responsibility Principle（单一职责原则）

5、VM->Docker（to PE）

6、DevOps (to PE)

        今天就对不胖不威的微服务架构做了一个简要的总结。路漫漫其修远兮，吾将上下而求索。

        我看你骨骼惊奇，是万中无一的科学奇才......