宜信微服务架构落地及其演进|分享实录

1、应用服务架构演进及微服务架构介绍

1.1 应用架构的演进历程

应用服务架构一直处于不断演进的过程当中，上图经过对比5种比较主流的架构模式，展现应用架构的演进历程和变化。

• 单体架构（All in One）。在业务发展初期，为了快速落地应用，知足客户需求，通常会使用All in One的单体架构。单体架构的特色是：全部模块都耦合在一个进程里，系统彻底封闭且很复杂，牵一发动全局。
• 竖井式架构（Vertical Application）。随着业务的增加，单体架构愈来愈臃肿，咱们对系统作了垂直化的拆分，应用架构进入第二阶段即竖井式架构。竖井式架构，就是根据业务属性将一个大的单体拆分红一些不一样的模块或子系统，子系统之间没有直接关联。竖井式架构依然存在紧耦合的问题，系统也是彻底封闭的，且存在大量的重复代码拷贝及模块功能需大量重复造轮子的状况。

单体架构和竖井式架构都是围绕web容器打包及部署的架构模式，随着业务的快速发展，要求实现服务的快速迭代和快速交付，应用架构也由此演进为以服务为中心的架构模式。主流的面向服务的架构模式有：RPC架构、ESB中心化架构和微服务架构。

• RPC架构。RPC架构在如今的应用系统中仍是比较常见的架构模式，适用于高并发场景，性能比较好。Dubbo就是一个典型的RPC架构。RPC架构也存在一些问题：经过共享分布式对象实现远程方法调用，若是在其中一个对象里添加一个属性，就会对共享对象的生产者与消费者产生影响，因此RPC架构也是紧耦合的模式，系统交互采用RPC私有TCP协议，服务生产者和消费者存在强代码依赖，异构系统集成不友好。
• ESB中心化架构。ESB中心化架构实现了松耦合，依赖于ESB消息总线技术实现异构系统的信息交互和集成集中式架构管理，所以它虽然是面向服务的，但它本质上依旧是一个中心化的架构。其优点在于：基于WebService技术，重量级的消息通信机制，咱们称之为“智能管道哑终端”，当团队规模比较大、要实现异构系统集成时，它能够提供统一的解决方案和技术实现方式，快速集成异构系统对外服务。ESB中心化架构的问题也比较明显：中心化架构难以知足灵活性的服务迭代和需求交付。
• 微服务架构。微服务架构实现了系统解耦和持续集成，有清晰的服务边界，粒度相对ESB架构和传统SOA架构来讲更小，使用轻量级的通信机制交互，具有更强的扩展性和弹性，可以更灵活、更快响应业务变化。

经过上述对比，咱们不难发现，应用服务架构是在不断演进的，并且其演进背后存在必定的逻辑，服务架构的演进主要取决于如下2个维度：

• 业务维度，技术架构是由业务发展所处的时期和阶段决定的，技术架构要可以解决业务发展过程当中的痛点。在进行架构选型时，须要考虑这个架构是否能知足当前业务的需求，业务需求可否随着架构的演进实现增量式的迭代。
• 技术维度，一方面要知足非功能需求，使得业务快速跟上技术生态的发展；另外一方面出于商业的技术考量，好比去IOE、 去V、 采用开源的技术解决方案的需求，逐渐完成服务底层使用的商业软件的技术隔离，知足业务快速交付。

1.2 微服务架构的定义

关于微服务的定义，此处引用ThoughtWorks首席科学家Martin Fowler给出的描述。

其中如下特性值得特别注意：

• 微服务架构是一种架构模式，提倡将单⼀应⽤程序划分红⼀组⼩的服务。
• 服务之间采用轻量级的通讯机制。
• 服务能够独立部署。
• 应当尽可能避免统⼀的、集中式的服务管理机制。
• 具体的⼀个服务能够选择合适的语⾔、⼯具对其进⾏构建。

Martin Fowler对于微服务架构的表述更偏向学术上的定义，没有给出明确的落地标准或规范，只是提供了一些构建微服务架构的原则。

1）面向开发者和业务实现

• 拆分红粒度小的服务。
• 各自独立的进程实现服务运行隔离。
• 服务运行经过轻量级的基于HTTP协议的RESTful API的通讯机制进行。
• 服务关注围绕业务领域之上构建。

2）面向服务的交付和运维

• 在服务交付方式上，强调可独立部署。
• 支持去中心化的设计，服务通常不须要集中化的管理。

1.3 如何筛选微服务

微服务架构模式有如此多的优势，那是否是全部的业务都要采用这种架构模式呢？又该如何筛选微服务？

左边图中，横坐标表明系统复杂度、纵坐标表明开发生产力、蓝色线表示微服务架构、绿色线表示单体架构。由图可知，当项目复杂度较低时，单体架构的生产力更高；随着项目复杂度愈来愈高，单体架构的生产力逐渐降低，微服务架构的生产力则显著提升。

1）3种场景能够考虑使用微服务（Are you tall enough? ）

• 规模大，团队超过10人。
• 业务复杂度高，系统超过5个子模块。
• 须要长期演进，项目周期超过半年。

2）其余因素筛选微服务

• 软件功能变化频繁，以快速迭代、缩短交付周期为核心的业务。
• 模块有独立的生命周期，微服务强调服务复用，减小重复造轮子，实现降本增效。
• 有独立的隔离性需求和扩展性需求（容错）。
• 简化的外部依赖。好比Facade模式场景，后端系统使用统一的对外暴露的形式提供服务。

1.4 如何拆分构建微服务

鉴别出哪些业务须要使用微服务架构模式后，须要决定如何拆分和构建微服务。

1）服务拆分

如何进行服务拆分，是在微服务过程当中业务方常常会问到的问题。

其实不少团队已经开始在作一些微服务化的工做，好比把大的工程拆分红不一样的模块或子系统，这种对业务模块进行的静态划分，至关于已经完成了微服务改造的第一步拆分。

上图是DDD（领域驱动设计）的开发模式，若是业务方案已经肯定采用微服务的架构模式，在整个工程领域咱们倾向于使用DDD模式来对业务架构和服务进行拆分。

DDD是基于领域模型的建模而不是数据库表驱动的建模，须要咱们对业务领域有深入的洞察，了解服务的边界和上下文信息传递。

康威定律指出：在微服务架构和设计系统组织，其产生的设计等价于组织间的沟通结构。就是说微服务架构不只是技术上的演进，同时对使用技术的组织提出了要求，拆分的服务是咱们和服务之间的沟通方式。

2）微服务构建

咱们采用微服务的12因子做为微服务建设的架构原则。微服务的12因子也叫云原生12因子，它提供了一种业务上云或微服务改造的最佳实践。重点介绍其中几个因子：

• 基准代码，建议项目使用一份基准代码、多份部署。项目在拆分时可能会存在多份基准代码，形成大量重复性的不一样版本的代码共存的现象。在进行微服务构建时，须要把公共服务和公共代码抽取出来，统一支撑不一样版本的业务。
• 显式依赖，显式声明依赖关系。对于 Java 程序，在 Gradle 或者Maven中写明依赖关系；
• 配置，在环境中存储配置。根据当前的环境变量决定使用什么样的配置文件。
• 后端服务，把后端服务当成一个附加资源。
• 构建、发布、运行的分离机制，强调服务和构建在运行时，不能够直接修改运行中的代码，而是须要经过构建发布流程统一发布。
• 无状态进程，以一个或多个无状态的进程运行应用。

1.5 微服务架构2种建设思路

微服务看起来很是好，但实际上是须要一个技术体系或平台体系来支撑的，若是没有这样一个服务架构平台体系的建设，不推荐使用微服务。

微服务架构建设分为2种思路：SDK模式、ServiceMesh模式。

1）SDK模式

典型表明是SpringCloud，SpringCloud是基于SpringBoot的一整套实现微服务的框架。SDK模式的底层运行平台能够是PaaS平台，也能够是Kuberneters平台或Docker容器。

• 优点：面向应用和开发人员，定制化、协议支持灵活，适合彻底自治的服务状态，方便线下调试，对操做系统平台无依赖。
• 缺点：应用需引入额外SDK依赖包，SDK自己占用内存及系统资源，对业务是侵入性的；须要构建微服务基础设施作业务能力支撑；须要使用SideCar模式实现异构系统集成。

2）ServiceMesh模式

Istio 是ServiceMesh模式的典型表明。ServiceMesh模式的优缺点与SDK模式正好相反。

• 优点：不须要额外引入SDK依赖包，对应用无侵入，且对Kubernetes自然友好支持。
• 缺点：部署比较复杂，对底层系统有必定的依赖；通信协议类型支持受限，须要依赖Mesh平台兼容。

2、SpringCloud微服务生态体系介绍

SpringCloud是基于SpringBoot发展而来的一整套成熟的微服务架构解决方案。SpringCloud具备如下优点：

• 面向开发者，以开发者为中心，开发者生态友好。
• 以Java技术栈为主要开发语言，代码可复用，微服务转型成本低。
• 基础设施完备，提供端到端的微服务架构解决方案。
• 有不少大厂作背书，如Pivital、Netflix,、alibaba等公司都是其生态和源代码贡献者，技术经历过大规模商业应用的考验。

2.1 SpringCloud的技术生态

SpringCloud自己也是一个逐渐演进的架构模式：最先是基于IOC/AOP的编程思想产生的；而后在Spring的基础上发展出SpringBoot，基于注解的方式实现快速的应用开发；后来在SpringBoot的基础上开发出SpringCloud底层微服务构架。

上图展现了SpringCloud的技术生态，SpringCloud技术栈包含了不少技术模块，好比Ribbon、Zuul、Eureka、SpringCloud Stream等，这些技术模块共同组成了SpringCloud生态圈，为开发者提供丰富的微服务架构基础设施支撑。

2.2 微服务和SpirngCloud架构的复杂性

微服务和SpirngCloud的架构是比较复杂的，如配置管理、服务注册与发现、API网关、打包部署调度、安全、服务故障自愈、流量控制和弹性伸缩等非功能需求，都是微服务须要包含的架构模块。上图中蓝色字表示SpirngCloud、Kubernetes等用来解决云原生和微服务架构问题的技术方案。

从图中能够看出微服务架构的复杂性，要想实现一套微服务架构来支撑和交付业务，须要在底层封装不少基础组件，构建一套底层基础架构来隔离底层的非功能需求，作到让业务系统无感知、平滑地对外提供服务。

3、宜信微服务架构和SIA网关的4种模式

SpringCloud提供的框架或基础设施是一个半成品，咱们在SpirngCloud的基础上进行了二次开发，抽象和封装了一些微服务架构的通用基础设施平台，不一样的业务团队共享这些基础设施，下降技术学习和接入成本，让业务团队更专一于业务逻辑的实现，聚焦业务开发。

3.1 宜信微服务架构

上图所示为宜信的微服务架构：

• 微服务网关，sia-gateway使用了去中心化的网关接入方案。
• 元数据服务层，用Eureka-plus和sia-config对注册中心Eureka和配置中心作了加强与优化。
• 任务管理，基于微服务的思想，开发和开源了微服务任务调度平台SIA-TASK。
• 容器平台，实现了快速的自动化构建、部署和服务编排。
• DevOps，微服务的交付频率、速度比较快，须要有持续集成、持续开发工具和手段来保障项目质量和服务正常运行，对此咱们有自研的UAVStack监控系统、自动化测试系统等工具链。

3.2 SIA微服务网关架构

有别于其余的架构模式，微服务架构里出现了一个重要的基础设施变化-增长了微服务网关模块。网关主要解决的问题是：服务拆分以后，每个服务粒度都比较小，服务之间的交互会呈现网状的结构，须要一个聚合的节点来聚合这些微服务。

所以咱们在SpringCloud微服务架构的基础上二次开发出SIA微服务网关，如图所示，重点介绍其中的2个核心模块：

• 网关组，网关组里封装了两种网关：同步网关和异步网关。
• OAM，自助式网关管理平台，全部业务节点的生命周期管理都经过这个模块来进行。

3.3 SIA微服务网关的4种模式

SIA微服务网关的4种模式：同步托管式、同步注解式、异步托管式、异步注解式。

1）同步托管式

采用单一源码库进行代码管理，交付方式是容器交付，去中心化的设计。目前大部分生产环境和业务都采用同步托管模式。

• 优势：网关交付对业务方彻底透明；只要在容器平台申请一个网关资源，就能够获得网关服务；基于Filter开发运维简单，容量小。
• 缺点：定制化不够强。

2）同步注解式

在跟业务团队对接时，咱们发现不少业务系统已经实现了一些独特的业务逻辑，难以迁移到网关，因此咱们采用一种比较兼容的注解的方式去适应这些业务逻辑，在原有项目的基础上加一个注解，将它们归入到整个网关管理体系中来。同步注解式是基于SpringCloud-Zuul 1实现的分布式微网关体系，管理业务方源码库，根据业务方环境进行交付。

• 优势：对项目的控制力比较强，业务团队独立运维，支持扩展定制化；基于Filter开发运维简单，容量小。
• 场景：业务定制化场景比较多。若是要加载初始化、加大资源，或对业务的Filter拦截机制有定制化需求，均可以用同步注解模式。

SpringCloud和Zuul使用的后端技术是基于Servlet，其线程处理模型是一个请求对应一个线程，当请求量过多，线程栈溢出，就会占用很是多的资源，致使网关没法提供额外的线程资源来处理新进来的请求。所以咱们采用了SpringCloud自研的SCG技术方案。

SpringCloud-Gateway基于Netty和反应式编程模式，采用收敛式的线程处理模型，只要用少数线程就能够处理高并发的流量请求。目前已经实现了基于SpringCloud-Gateway的异步模式，当同步模式在线上运行过程当中出现资源透支的状况，就选择使用异步模式。异步模式也分为2种：异步托管式、异步注解式。

3）异步托管式

经过单一源码库进行代码管理，采用容器交付。主要使用场景是流量型，若是业务多对高并发、高吞吐场景，建议使用异步托管式。

4）异步注解式

若是想在异步网关基础上作定制开发，可使用异步注解的模式。

网关的4种模式来源于业务的需求：为兼容业务已有逻辑演进出注解模式；当出现性能瓶颈、资源浪费时，采用异步模式应对高并发流量。

上图是网关测试环境的一个截图， 包括上述4种模式。每个小方格表明业务的一个网关组，方格中的小圆圈表明它属于哪种网关。业务系统在选择网关模式时要作一个判断：诉求是支持业务的快速集成，仍是对流量有必定要求。

3.4 SIA微网关的核心Feature

如图将SIA微网关的核心Feature分红2个层面：

• 数据面，负责数据包的处理逻辑。路由转发、负载均衡、灰度发布、日志审计、熔断限流等都是从数据层面对流量进行管理。
• 控制面，负责服务粒度上的管理。统一视图管理、多租户管理、注册中心、配置管理、路由组件绑定等是从控制层面来保障和管理服务。

3.5 SIA微网关对微服务的生命周期管理

微服务网关贯穿了整个微服务生命周期的管理。

SIA微服务网关的功能包括：

• Swagger UI、模块复用对应服务文档中心模块的功能。
• 动态路由、共享能力集中在分布式网关节点。
• 日志管理、管控组件是网关Master提供的功能。

各功能模块对应的生命周期：

• 服务文档中心，对应整个软件生命周期的初期开发和设计阶段，网关提供一个个统一的API视图，前端和后台能够经过Swagger UI来联调开发。
• 分布式网关节点，在开发和部署阶段会涉及到一些共享能力的部署和运行。
• 网关Master，在运维阶段经过自动化运维提升运维效率；在管理方面，提供数据统计的功能，生成数据报告用于管控。

SIA微服务网关做用于软件生命周期的各个阶段，经过标准协同、业务测试/前端后端沟通、服务模块复用、可视化管理、数据统计管控等实现业务的统一融合、降本增效。

3.6 总结：微服务架构与中台&后台

2016年，Gartner 发布了一个关于应用变化速率的报告《Pace-Layered Application Strategy》，以应用变化速率为标准将业务应用分为三层：

• SOI-敏态业务：好比互联网业务，需求变动快，要求快速迭代 、快速交付。
• SOR-稳态业务： 好比传统业务，变动周期⻓、变化频率低、变化成本高、变化⻛险高。
• SOD-中台业务： 齿轮匹配失衡，中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，提高⽤户响应力。

中台的目标是围绕业务组织进行可复用能力的有机整合，协助业务落地实施、改造、试错、转型，提高组织效率，下降系统成本。

中台和微服务有什么关系呢？微服务架构是面向开发的架构，不少基础服务能够沉淀到微服务架构里，同时，微服务架构把中台的能力快速释放出来，知足敏态业务快速变动的业务需求。

4、应用场景及典例分析

4.1 分解&聚合

上图是路由管理里的一个截图，当一个大的单体或不一样的服务要对外提供统一服务时，能够把服务聚合到网关上；同时一个巨型应用也能够经过网关分解成微服务。

4.2 复用&个性化

微服务架构中有不少非功能需求，或者说是技术导向型的需求，包括日志管理、限流、蓝绿部署、版本管理等，能够经过组件的方式下沉到网关上，业务系统经过将服务与组件绑定实现对组件功能的复用。

咱们还提供了一个插件机制，当业务有独特的需求，能够根据其业务逻辑在网关上进行功能的个性化定制。

4.3 API&契约

在开发或先后端联调时，先后端能够经过网关服务文档中心的Swagger UI功能模块访问后端服务调用接口的分析。

只要在后端服务之上加一个Swagger注解，网关就能够把全部对外暴露的服务抓取出来，这至关因而一种契约式的开发。

4.4 容错&保护

咱们对网关应用作了容错和保护机制，固然这也是SpringCloud自己自带的一个技术模块，咱们的容错机制是基于SpringCloud的Hystrix实现的，当发现后端服务调用请求一直在返回错误时，会开启熔断，避免因为一直发送错误请求致使雪崩的状况发生。

除此以外，咱们还会采用Guava限流的方式对服务进行保护。在大促或秒杀的场景下，会有大量请求进来，这时会经过限流来保护服务的稳定。

4.5 监控&治理

宜信微服务架构平台有一个很重要的功能是网关服务运行状态和后端链接状态可观测，提供了不少监控方面的功能组件，如图所示，能够统计当前请求的频率、服务健康度。

预警方面重点介绍网关拓扑图。当请求失败，当前链路出现异常，经过网关拓扑图能够快速跟踪和判断业务系统哪一个节点出现问题，而后对有问题的节点进行摘除或其余操做。

咱们的网关运行在Docker平台上，Docker平台在出现问题或重启以后日志会丢失，咱们的日志系统会把日志归集，存储到ES中，便于对历史日志溯源。

4.6 统计&分析

网关中有一个组件叫“监控统计”，这个模块默认是不打开的，若是你想对请求作延时，或者想看请求的明细调用状况，能够经过组件管理中打开这个组件，对容器的请求作统计和分析。监控统计组件会对当前请求的最大延迟、最小延迟、失败个数、平均延迟进行排序，一目了然。

5、微服务化架构建设遇到的问题

5.1 设计初期的问题

1）如何隔离业务网关，同时有统一的管理视图？

构建微服务网关初期，业务同事比较关注咱们的业务网关和别人的网关是否存在耦合问题，他的业务请求是否会影响到我。咱们选用去中心的网关设计方式，同时经过OAM实现对全部网关节点的统一管理。

2）平台型系统建设初期是否要考虑同步异步网关融合？

咱们的微服务网关是按照DDD领域驱动模式来建设的，没有把网关绑定在某一个特殊的技术实现上，而是把它做为一个抽象封装来统一管理后端的节点，若是换一种技术实现也不会影响到前端业务的正常工做。所以在架构建设初期要考虑清楚你的业务系统和后端技术架构之间是否解耦。

5.2 使用开源方案的问题

3）开源系统自己的bug

虽然每一种开源方案在开源以前都通过了长时间的考验，但其实依然可能存在bug，基于这些开源方案进行二次开发时仍可能遇到一些坑，咱们会不断对开源系统进行bug修复和功能加强。

4）系统的性能问题

Zuul自己存在性能瓶颈，当出现性能问题时，咱们考虑是否是要用线程收敛的模式来加强网关的性能。

5.3 上线生产运维方面的问题

5）如何克服Eureka注册中心的CAP问题？

在网关应用中会遇到Eureka的CAP问题，由于Eureka消息注册以可用性（Availability）优先，在一致性（Consistency）上相对较弱。为解决这个问题，咱们基于Eureka的特色提供SynchSpeed服务，若是业务须要保证状态一致性，能够开启这个服务。

6）SpringCloud与SpirngBoot不一样版本的兼容问题？ K8S平台与微服务注册中心状态同步？

这两个问题是指当云容器平台的状态发生变动，却没有及时通知到注册中心，致使服务在两个平台的状态不一致，这就须要作上下文关联系统（StakeHolder）的整合。

内容来源：宜信技术学院第8期技术沙龙-线上直播|宜信微服务架构落地及其演进

主讲人：宜信高级架构师 & 宜信科技中心基础研发部SIA微服务网关负责人王佩华