大火“微服务架构”详解与实践

1.业务背景 1.1 产品状态 1、各产品系统独立开发，代码复用率低。系统之间相互调用，耦合严重。系统解耦和独立部署困难。 2、传统的单体架构变得越来越庞大、越来越笨重；当新功能的开发、功能的重构不再敏捷可控时；测试人员的回归测试边界很难弄清楚；系统的线上部署也变得困难 3、高并发访问下无法提供可靠服务 4、严重缺乏持续集成、持续部署、持续交付等工程效率工具。 5、严重缺乏监控系统、日志分析等系统稳定性工具。 所有上述情况都导致我们对需求变化的反应缓慢。​ 1.2 业务需求 架构绝对是为业务需求而生的。我们首先看一下我们面临的业务需求及其特点。平台主要满足餐饮新零售下餐饮企业的管理和运营需求，以及产品和运营团队两大类业务需求。 具体来说： 1、餐饮新零售下餐饮企业管理运营痛点 如何提高营销能力和管理会员，以更低的成本为餐饮企业带来更多的利润 如何对数据进行深度挖掘和分析，帮助决策者做出运营决策 如何掌握实时数据，让决策者及时了解餐厅运营情况 2. 对于产品和运营团队 主要是提高产品管控能力，促进整体系统的良好运行 因此，开发SAAS服务产品刻不容缓，需要满足快速开发、灵活升级、高性能、高可用、高稳定性、简化运维等更高要求。​ 这一步的转变不是“快”和“慢”，而是“生”和“死”。 2. 微服务概念 专注于职责单一、功能独立的服务，以模块化的方式组合大规模应用。​ 2.1 特点 中心化架构：单一无分散 分布式架构：分散压力 微服务架构：去中心化能力 2.2 微服务架构的优点 每个微服务组件简单灵活，可以独立部署。不再像单体应用时代那样，应用需要庞大的应用服务器来支撑。 小团队可以负责更加专注和专业，从而更加高效和可靠。 微服务是松散耦合的，微服务内部具有高度内聚性，使得每个微服务易于按需扩展。 3.微服务技术选型和微服务问题 3.1 技术选型 3.1.1 技术矩阵总结 Netflix提供更全面的解决方案 Spring Cloud对Netflix的封装比较全面 Spring Cloud基于Spring Boot，团队有基础 Spring Cloud提供了Control Bus来帮助实现监控和隐藏点。业务应用部署在阿里云上。 Spring Cloud支持12 Factors和Cloud-Native，有利于在云环境中使用。 3.1.2 团队期望 首先支持休息 团队的技术栈和例子都比较单薄，我们希望有平滑的学习曲线和对新技术的坚持能力。 小团队，希望有更全面的解决方案 目前团队主要使用Spring Cloud + Spring Boot来实现面向服务 详细的技术选型分析请看我之前的文章《我的技术选型》。 3.2 微服务带来的问题 跟踪依赖服务的变化是很困难的。其他团队的服务接口文档过时了怎么办？如果依赖的服务没有准备好，如何验证我开发的功能？ 有些模块是重复构建的，跨团队、跨系统、跨语言都会有大量的重复构建。 微服务放大了分布式架构中的一系列问题，比如如何处理分布式事务？依赖服务不稳定怎么办？ 运维复杂度急剧增加。例如，大量部署对象、多个监控流程导致整体运维复杂度增加。​ 以上问题我们肯定都遇到过，也总结形成了一些自己的解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架；实现统一认证、统一配置、统一日志框架、分布式汇总分析；采用全局事务方案，使用异步模拟同步；搭建持续集成平台、统一监控平台等。 微服务架构是一把双刃剑。虽然它解决了集中式架构和分布式架构的问题，但也带来了上述问题。因此，我们需要一个微服务应用平台来整体解决这些问题。 4. 微服务架构设计 4.1 微服务应用架构设计原则 4.2 微服务应用架构设计目标 微服务架构设计的目标是满足快速开发、灵活升级、高性能、高可用、高稳定性、简化运维等更高需求。​ 4.3 微服务应用整体架构 微服务应用平台的整体架构主要从开发集成、微服务运行容器和平台、运行时监控和治理、外部渠道接入等维度进行划分和考虑。 开发集成：主要是搭建微服务平台需要的一些工具和仓库 运行时：微服务平台需要提供一些基础能力和分布式支撑能力。我们的微服务运行容器将运行在这个平台上。 监控和治理：致力于托管微服务运行时的统一监控和配置。 服务网关：负责与前端WEB应用、移动APP等渠道集成，对前端请求进行认证，然后进行路由转发。 4.4 微服务框架概述这里我不会详细解释服务框架中的每个组件，而是会在另一篇文章中进行解释。 5. 微服务架构设计与实现 5.1 基础环境 对于企业的IT建设来说，三个基础环境非常重要：团队协作环境、服务基础环境、IT基础设施。 团队协作环境：主要在DevOps领域，负责从需求到计划任务、团队协作、质量管理、持续集成和发布的一切。 服务基础环境：指微服务应用平台。其主要目标是支持微服务应用程序的设计、开发和测试、运行时的业务数据处理以及应用程序管理和监控。 IT基础设施：主要是各种运行环境支撑如IaaS（VM虚拟化）和CaaS（容器虚拟化）等实现方式。 5.2 服务通信 服务之间的通信通常使用HTTP+REST和RPC通信协议。 HTTP+REST，服务约束完全取决于提供商的意识。 其特点是简单、开发和使用友好。 缺点是难以管理、无状态连接、缺乏复用、服务器推送等。 RPC 为通信双方定义了数据约束。 连接多以长连接为主，提高性能，并附带服务器推送、呼叫链路监控和埋点等，增强了系统的附加能力。 缺点是对调用端提出了新的要求。 综合来看，RPC在性能和合约优先级方面具有优势。如何最大限度地发挥其优势，避免其劣势？ 引入GateWay层是为了融合REST和RPC的优点，在GateWay层提供REST访问能力。 5.3 服务注册/发现 过去，单个应用程序相互调用时，配置一个IP或域名就足够了。然而，微服务架构下，服务提供商众多，手动配置IP地址或域名就成了一件耦合而繁琐的事情。那么自动服务注册和发现的方案就解决了这个问题。 我们的服务注册发现能力是依靠SpringCloud Eureka组件实现的。服务启动时，会将自己想要发布的服务注册到服务注册中心；运行时，如果需要调用其他微服务的接口，必须先去注册中心获取服务提供者的地址。拿到地址后，通过微服务容器内部的一个简单的负载均衡周期来完成路由。 尤里卡服务器特点： Eureka Client缓存服务注册信息 Eureka Server的注册信息只保存在内存中 Eureka的注册只针对应用层面，不支持更细粒度的服务注册，比如单个服务Rest该服务每 30 秒向 Eureka Server 发送一次心跳。不建议修改心跳时间。 Eureka利用这个时间来判断集群中是否存在大规模的服务通信异常。 如果15分钟内85%的服务没有更新，Eureka Server将停止删除注册的服务，以确保注册的服务信息不丢失。 Eureka Server之间的数据同步采用全量拉取和增量同步方式 Eureka在分布式事务中满足CAP理论中的AP 5.4 集中配置管理 在微服务分布式环境中，当一个系统被拆分成很多微服务时，我们必须告别运维中手动修改配置配置。需要集中配置管理，提高运维效率。 配置文件主要包括运行前的静态配置和运行时的动态配置。 静态配置通常在编译部署包之前设置。 动态配置是系统运行过程中需要调整的系统变量或业务参数。 要实现集中配置管理，需要注意以下几点。 配置和媒体的分离需要规范的控制。 配置方式要统一，格式、读写方式、变更热更新方式尽量统一，采用统一的配置框架。 运行时需要一个配置中心来统一管理业务系统中的配置信息。 概念抽象： 介质是源代码编译的产物，与环境无关。应该在多个环境下共享，如：jar 5.5 统一认证与鉴权 在安全认证方面，我们使用Spring Security OAuth2 + JWT创建安全令牌，实现统一的安全认证和鉴权，实现微服务之间的按需隔离和安全互操作。 认证必须是一项公共服务，而不是单独构建多个系统。 5.6 分布式调用 微服务架构下，相比传统部署方式，分布式调用较多，因此“如何在不确定的环境下交付某些服务”可以简单理解为我所依赖的服务的可靠性。如果没有保证，我如何保证我能够正常提供服务，并且不会被我所依赖的其他服务拖垮？ 我们采用的计划： 合理的超时时间 合理的重试机制 合理的异步机制 合理的限流机制（调用次数和频率） 合理的降级机制 合理的断路器机构 建议采用SEDA架构来解决这个问题。 SEDA：阶段式事件驱动架构本质上是一种采用分布式事件驱动模型、采用异步模拟同步、非阻塞等待、资源分配隔离的解决方案。​ 5.7 分布式事务分布式事务 C 分布式环境下多个节点的数据是否强一致？ A 分布式服务始终能保证可用性 P网络分区容错 分布式事务策略 避免跨数据库事务，并尽可能将相关表保留在同一个数据库中 2PC 3PC TCC补偿模式等，耗时且复杂 基于MQ的最终一致性简单、高效、易于理解 将远程分布式事务分解为一系列本地事务 基于MQ的分布式事务 5.8 服务拆分 服务拆分方式 AKF扩展立方体是应用程序扩展三个维度的抽象总结。 X轴扩展部署实例是指单个系统多运行几个实例，形成集群加负载均衡的模型。 业务领域的Y轴划分是根据不同的业务划分。 Z轴数据隔离分区。例如，当共享单车用户数量增加时，集群模式就无法支撑。然后根据用户请求的区域对数据进行分区。北京、上海、深圳等地又建设了多个集群。 服务拆分要点 低耦合、高内聚：一个服务完成一项独立的功能 根据团队结构：小规模团队维护，快速迭代 5.9 数据库拆分 单个数据库、单个表很难支撑不断增长的业务量和数据量。当服务拆分时，数据库也会随之拆分。 5.9.1 模式 垂直分割 水平分割 5.9.2 原则 尽量不要分开 避免跨数据库事务 单米级1000w 避免下垂连接（冗余、全局表） 5.10 日志管理 日志主要分为三种类型：系统日志、业务日志和跟踪日志。通过这些日志，可以帮助我们在出现问题时获取一些关键信息来定位问题。 为了能够追溯问题的根源，我们需要一个能够连接整个请求调用链的标识符。这个标识符可以让我们快速定位到问题发生的具体时间、地点和相关信息，快速恢复业务。完整交易链接。对这些日志和管道的详细处理，对于定位系统运维问题非常有帮助。通常开源框架只提供基础框架，在设计平台时必须考虑直接提供统一标准化的基础能力。 分布式追踪 5.11 服务合同和API管理 针对前面提到的微服务带来的依赖管理问题，我们需要提供API管理能力。说到API管理，首先要提到的就是服务契约。 服务契约主要描述服务接口的输入输出规范以及与服务调用集成相关的其他规范。 5.12 服务契约和服务模拟通过服务契约，开发者可以方便地获取依赖服务的变化，根据依赖服务的变化及时调整自己的程序，并方便地进行模拟测试和验证。 根据合约生成模拟服务，就是我们常说的服务挡板。这样，即使其他依赖服务无法提供功能，我们也可以使用挡板进行联调测试。 5.13 微服务容器 我们希望构建一个稳定、高效、易于扩展的微服务应用程序。事实上，我们还需要做很多事情。如果没有统一的微服务容器，这些能力就需要构建在每个微服务组件中，并且很难集成。有了统一的微服务运行容器和一些公共基础服务，前面提到的微服务架构下一些组件重复建设的问题就迎刃而解了。 5.14 持续集成和持续部署 在运维方面，我们首先要解决的是持续集成和持续交付。我们可以很方便地利用持续集成环境将程序编译成媒体包和部署包，并持续稳定地部署到各个环境中。 概念抽象： Media：是源码编译出来的产品，与环境无关。它应该在多个环境中共享。如：罐子 配置：是环境相关的信息。 部署包=配置+介质。 5.15 微服务平台、容器云与DevOps的关系 至于微服务应用平台本身，并不依赖于DevOps和容器云。开发的部署包可以运行在物理机、虚拟机或者容器上。然而，当微服务应用平台将DevOps和容器云结合在一起时，我们会发现持续集成和交付变成了一个非常简单、方便、可靠的过程。只需几个简单的步骤，即可设置整个开发、测试、预发布或生产环境。 整个流程的复杂性被平台屏蔽了。通过三个基础环境的融合，我们可以让分散的微服务组件的统一管理和运维交付更加简单便捷。 5.16 技术团队的组织 技术团队组织——小团队 根据“康威定律”，软件架构是由组织结构决定的。因此，按照贝索斯的“双披萨”团队理论和敏捷方法构建小团队，可以有效降低沟通成本，促进团队自治。 。 通过拥有一个结构比较全面的小团队，Leader（熟悉业务和技术）+前端工程师+后端工程师，我们往往可以相对独立地承担一个或几个业务的工作。这样，团队成员整体负责一个或几个业务模块，可以大大提高团队成员的参与感、使命感和责任感。团队成员互相帮助，有高度的自主权。每个人要么一起成功，要么一起失败。 技术团队组织——团队划分团队根据业务线划分。随着业务复杂度的增加，可以按照业务/子业务线划分团队，但并不是绝对扁平化，而是严格遵循两比萨原则。 业务线往往是按业务来划分的。技术团队负责支持各业务线。因此，技术团队通常是按系统或业务来划分的。两个披萨团队的原则适用于组织层次结构的任何部分。当人太多的时候，分裂就必须继续。 技术团队组织——团队合作 技术团队组织——结果导向 1.所有权 2.行动偏见 3.吃你的狗粮 工程师负责从需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列工作。换句话说，软件工程师负责应用或服务整个生命周期的所有工作。 运维是团队成员的首要任务。在强大的自动化运维工具的支持下，软件工程师必须对服务或应用的SLA负责。 4、开发人员参与架构设计，而不是架构师参与开发 研发人员是所有者，对业务和团队负责 强调抽象和简化，将复杂问题分解为简单问题并有效解决，避免过度设计 鼓励使用新技术解决问题，但强调控制 6、微服务架构设计过程中积累的经验 深入了解业务 设计阶段要追求完美，实践阶段要考虑实际情况并做出平衡。 容错能力 先监控 任何回滚都可以在线完成 七、总结 微服务架构是技术的升级，但更多的是管理模式的升级和思维的转变。