以下内容来摘抄自项目汇报材料：

微服务是一种架构风格，它是以专注于单一任务的小型功能模块为基础，利用模块化的方式，将多个（或一个）小型功能模块组合成复杂的大型应用程序；各功能模块之间虽然松散耦合，并使用与语言无关的API（例如http接口）相互通讯，但在总体功能上表现为一个统一的整体。每个微服务的开发和维护相对容易，且可以独立部署，因此采用微服务框架的系统功能伸缩性强，是应对当前及今后快速变化的业务需求比较好的选择。



近年来，各企业信息化建设在传统技术架构的基础上，计算、存储等资源逐步向虚拟化过渡，并积极探索数据库和应用中间件资源池，为信息化发展奠定了坚实基础，但在新技术的引入，在技术架构的统一性、标准性上仍有一定差距。在信息系统开发运行层面，多种技术路线并行，缺乏统一的技术组件和开发部署标准，质量管控和集成整合困难是当前比较突出的现象。

正是由于之前多种技术路线并行，不少已建成的应用系统为“烟囱式”系统，其优势是应用开发相对简单，且易于测试。但“烟囱式”系统常采用比较独立的架构设计，系统规模越大、数量越多，信息化壁垒程度就越深、信息化孤岛现象就越突出，各系统之间的集成和交互就越困难，多系统之间的协作、沟通成本也随之增加。

采用传统的技术架构构建的“烟囱式”应用系统，通常存在以下问题：

1、重复的功能建设导致数据一致性难以保证。由于技术架构不统一，且缺乏统一的技术组件，构建出的应用系统复用能力不足，因此不少应用系统中存在着相同的功能模块。功能的重复建设造成同样的数据在不同的系统内都有产生，而各系统之间产生的数据却有可能不一致。这些系统相互平行，无法确定哪个数据是有效的。公司两化融合发展规划明确提出要以提高业务数据质量为目标实施数据质量管理，数据对业务的驱动能力也需要进一步提升，而确保数据的一致性则是这一切的前提。

2、打通“烟囱式”系统间交互的集成和协作成本高昂。随着企业业务的发展，要打通这些“烟囱式”系统间的连接，就必须基SOA理念，对这些“烟囱式”系统进行服务化改造。但具体实施改造时，会牵涉大量的协同、开发及运维成本，改造时间长，效率低。

3、不利于业务的沉淀和持续发展。传统的应用系统建设，一旦系统上线后，就进入了运维阶段，在运维阶段难免会存在对系统功能的完善和对新业务需求的升级，由于“烟囱式”系统，不能共享业务逻辑，也无从获取业务逻辑及升级途径，从而带来系统功能的重复开发。导致服务得不到沉淀和持续发展。

根据以上现状及问题，结合两化融合工作发展规划要求中“厚平台、薄应用”的指导思想，我们考虑以服务化的理念构建应用系统。所谓服务化，就是将一个系统根据业务功能划分为多个模块（或子系统），模块之间的交互以服务的方式进行。



微服务框架则是服务化理念构建应用系统的落地方式。这里简要回顾技术架构的发展历程：

1、单一应用架构。当应用访问量很小的时候，往往会把所有的功能部署在一起，以降低成本；随着应用功能的增多，代码量越来越大，越来越难以维护。

2、垂直应用架构。当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，于是开发人员将应用拆成互不相干的几个应用，以提升效率；但垂直架构中相同逻辑代码需要不断的复制，不能复用，每个垂直模块都相当于一个独立的系统。

3、分布式服务架构。当垂直应用越来越多，应用之间交互不可避免，这时可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。然而随着服务越来越多，需要管理的服务地址也越来越多，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况实现动态管理。

4、流动计算架构。当分布式服务架构中服务越来越多，容量的评估，服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率；不过服务间会有明显的依赖关系，一旦某个环节出错会对整个应用产生较大影响，服务之间关系复杂，运维、测试部署困难。

5、微服务架构。微服务就是将一个单体架构的应用按业务划分为一个个的独立部署运行的程序（即服务），每个服务仅关注于完成一件任务，各服务之间是松耦合的，相互之间通过 HTTP 协议进行通信。开发微服务时，关注的重点不是服务的大小，而是服务间的松散耦合，这样能够自主地对每个服务进行开发、测试、部署和更新。当然，在设计微服务时，只要与其他微服务没有过多的直接依赖，就可以尝试让它们尽可能地轻小。因此比微服务的大小更重要的是，它必须具有足够的内聚性，并且能够独立于其他服务。

采用微服务框架的应用系统：

1、数据一致性好。由于功能可以被充分复用，同一项功能只需要构建一次，后续需要使用该功能时，只需调用已有的服务即可，这样一来就做到了“数出一门”，避免了多个系统数据不一致无法判定数据有效性的问题。功能复用既解决了数据的一致性问题，又使得应用代码更加轻巧，同时也有利于节省项目投资。

2、协作成本较低。微服务框架通常有统一的服务接口规范，体系内的各个微服务根据服务接口规范，以对外发布标准接口的方式提供服务能力。只要是在统一规范的约束下，无论哪个项目开发的微服务，都能被顺利的接入微服务体系，相比传统架构系统之间的对接，团队、系统间的协作成本大大降低。

3、利于服务的逐步沉淀。随着服务化的不断深入，各项业务功能中通用的、共性的部分将逐步沉淀成为功能稳定的微服务，既为后续业务需求的落地提供有力的支撑，又利于节约成本。

此外，相比传统技术架构，微服务之间松散耦合的特点，也为系统的更新、升级，以及功能伸缩性带来了更大的优势。

采用微服务框架对应用系统服务化进行落地时，也会带来一些挑战，比如大量的微服务如何管理、遇到故障如何排查、如何保证功能的高可用等。



为应对挑战，微服务框架采取了一系列方法对服务进行治理。

1、微服务的管理

对数量众多的微服务，通常采用以下方式进行管理：

(1)服务注册中心

服务注册中心的引入提供了服务的自动发现和注册机制，服务启动时向服务中心动态注册，提供服务名称和IP地址及端口，客户端根据服务名称调用服务。

(2)服务网关

服务网关作为服务访问的总入口，起“扎口管理”作用，在网关上可以集中处理路由转发、负载均衡、限流熔断、日志监控、安全授权等操作。同时服务网关具有反向代理作用，能有效隔离外部访问和内部服务。

(3)安全管理

本项目中采用服务网关+权限集中管理方式进行安全管理，安全组件位于网关中，提供集中的身份识别、授权、认证等服务。外部请求必须经过服务网关，获取身份识别后，才能进入后台服务池。

2、故障排除

微服务框架中通常都有链路追踪组件，在出现故障时，为分析故障原因提供参考依据。

链路追踪组件通过为每次服务、每次调用打上独立标签，实现在复杂的服务调用中精确定位问题的功能；如果某个接口突然耗时增加，可以直观地展示出服务调用及处理的耗时情况，为使用人员分析服务的性能瓶颈提供数据支撑。

3、高可用保障

为确保众多微服务组成的应用系统对外提供可靠的服务，一方面是通过服务节点的冗余保障高可用，另一方面还要防止出现因服务依赖而产生“雪崩现象”。

(1)负载均衡

一般情况下，服务节点经常不是唯一的，每个节点的服务能力也可能不同；负载均衡组件能够检测每个服务的心跳、统计每次调用的响应时间，结合丰富的负载均衡算法，动态进行平衡。负载均衡组件常包含在其它组件内。

(2)限流熔断

相比传统架构，微服务框架的组件及功能之间的交互大量增加，使得微服务框架比传统架构更加依赖网络环境。为保证各项微服务的高可用性，需要在服务或网络出现拥塞或故障时，及时隔离暂时不可用的服务。限流熔断机制通过统计每次服务调用的状态，实现对异常服务自动隔离，防止出现因服务依赖而产生的“雪崩现象”，并且提供重试机制，待异常解决后能自动恢复。限流熔断组件常包含在服务网关中。

总体来说，服务治理的目的是让整个微服务体系高质量的对外提供服务，同时确保高可用和可维护性。以上是服务治理最常见的手段，具体实施中的治理手段及功能组件更加丰富。



通过近期以来的学习调研，我们从多个角度了解了微服务框架，并结合两化融合发展规划分析了微服务框架相比传统架构的优势，同时梳理了采用微服务框架将带来的挑战及应对措施。通过深入分析，我们认为微服务框架采用有效方式对其所辖的微服务进行统一治理，使得整个体系能够有序、高效运行，并保持高可用性，同时又能解决传统架构带来的数据一致性差、协作成本高、不利于业务沉淀发展等问题，因此我们认为以微服务框架构建应用系统具备较为充分的可行性。



根据微服务框架 Dubbo 架构图画出 Dubbo 进行一次微服务调用的时序图。



第十周作业，根据微服务框架Dubbo架构图画出Dubbo进行一次微服务调用的时序图。

服务端启动时，自动向注册中心注册地址，并定期发送心跳，让注册中心维护一个可用的地址清单。客户端定时拉取注册中心的地址清单。客户端本地通过软负载均衡选择客户端地址，然后发起请求。请求过程由框架封装调用细节，简化客户端调用代码，视同于本地调用