十三、微服务设计的原则及价值

十三、微服务设计的原则及价值

• 前面已经介绍了TSF的基本功能以及使用，接下来我们再回到微服务上面来；
• 微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务，而不是一味将服务做小。代码量的多少不能作为微服务划分的依据，因为不同的服务本身的业务复杂性不同，代码量也不同。在微服务的设计阶段，就应确定其边界。微服务之间应该相对独立并保持松耦合。接下来我们看一下基于TSF的微服务设计的原则及价值。

学习目标

通过本文的学习，你将可以：

• 了解微服务的设计目标
• 掌握微服务的设计原则
• 了解微服务化带来的价值

第一章 微服务的设计目标

1.1 微服务的设计目标

• 微服务架构是一种架构模式，将单体应用划分为一组服务，服务之间互相协作，为用户提供最终价值
• 每个服务运行在其独立的进程中，服务间采用轻量级的通信机制协作（通常是基于RESTful API）
• 每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

• 设计和交付：要做到标志化，把应用拆分成独立的小服务，持续部署，通过自动化工具减少重复工作量，提供工作效率，让开发人员有更多的时间关注业务，以业务为中心。
• 系统架构原则：
  • 减少惯性思维，迅速做出有利于自己的选择反馈，减少团队间的依赖；
  • 消除偶然的复杂性，替换不必要的复杂过程、系统和集成，以便我们能够集中精力于问题的本质；
  • 一致的接口和数据流消除重复的数据和创建清晰的记录系统，具有一致的集成接口；
  • 没有银弹，现成的解决方案提前交付有价值，但会产生惰性和偶然的复杂性；
• 战略目标：最终打造可扩展的弹性业务系统，助力产业在新领域扩展，在已有市场业务中，不断创新保持领先身位。

第二章 微服务的设计原则

2.1 微服务的设计原则简介

• 业务领域蓝图：告诉我们的最大价值我觉得是，当我们要开发一个系统时，应该尽量先把领域模型想清楚，然后再开始动手编码，这样的系统后期才会很好维护。
• 全维度可视化：从不同维度实现可视化，如TSF中提供了服务拓扑，服务监控，调用链等
• 全流程自动化：自动化一切可以自动化的，降低部署和发布的难度
• 容错设计：自动化容错设计，如熔断器，集群
• 去中心化设计：提供服务的扩展能力
• 独立部署：服务可以独立部署

2.2 TSF与微服务设计原则

• 基于微服务设计原则的TSF平台介绍
  • TSF与全维度可视化
  • TSF与全流程自动化（devops）
  • TSF与微服务容错设计
  • TSF与微服务去中心化设计
  • TSF与平台去中心化设计
  • TSF与独立部署
• 接下来看一下在TSF中体现的微服务设计原则

2.2.1 TSF与全维度可视化

• 调用链查询用来查询和定位具体某一次调用的情况。使用者可以通过具体的服务、接口定位、IP等来查询具体的调用过程，查找调用过程所需要的时间和运行情况。
• 通过调用链详情，可以根据TraceID查询调用链的详细信息。调用链详情是为了定位在分布式链路调用过程中每个环节的耗时和异常（不包含本地方法调用情况，本地方法调用建议使用业务Log的方式记录）。
• 通过调用链通常为了解决如下几个问题：
  • 定位耗时较长的服务
  • 不合理的调用逻辑（如一次请求多次调用某服务，建议改为批量调用接口）

2.2.1 TSF与全维度可视化（续）

• 可以再服务治理中通过服务拓扑图中的颜色块区别正常与异常访问的请求，通过可视化，具体日志方式可以方便快速的定位问题点

2.2.2 TSF与DevOps

• DevOps整体结构及业界生态

  

• TSF打通了从微服务开发到部署的整个流程，同时整个流程借助自动化工具实现了持续集成，持续发布到持续运营的目的。真正打通了DevOps的闭环生态

• DevOps是一个完整的面向IT运维的工作流，以IT自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

• DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。

• 换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了DevOps能力图（如图1），良好的闭环可以大大增加整体的产出。

2.2.2 TSF与DevOps（续）

• 在TSF中把基础框架构建全部通过自动化框架代码生成，开发人员只需要引入代码就可以快速完成基础框架代码构建，让开发人员更多的关注业务

• 测试过程中，把单元测试，集成测试。回归测试等通过自动化测试工具完成，同时实现灰度发布，自动回滚功能，相比原有传统方式大大减少了工作量。

2.2.3 TSF与微服务容错设计

• 优雅的服务降级：微服务架构的最大优点之一是您可以隔离故障，并在当组件单独故障时，进行优雅的服务降级。例如，在中断期间，照片共享应用程序中的客户可能无法上传新图片，但仍可以浏览、编辑和共享其现有照片。

• 变更管理：在微服务架构中，服务依赖于彼此。要处理变更中的问题，您可以实施变更管理策略和自动回滚机制。

• 健康检查与负载均衡：实例由于出现故障、部署或自动缩放的情况，会进行持续启动、重新启动或停止操作。它可能导致它们暂时或永久不可用。为避免问题，您的负载均衡器应该从路由中跳过不仅阿卡的实例，应用实例健康状况可以通过外部观察来确定。您可以通过重复调用GET/health端点或通过自我报告来实现。现在主流的服务发现解决方案，会持续从实例中收集健康信息，并配置负载均衡器，将流量仅路由到健康的组件上。

• 自我修复：可以帮助应用程序从错误中恢复过来。当应用程序可以采取必要步骤从故障状态恢复时，我们就可以说它是可以实现自我修复的

• 舱壁模式：工业中使用舱壁将船舶划分为几个部分，以便在船体破坏的情况下，可以将船舶各个部件密封起来；船壁的概念在软件开发中可以被应用在隔离资源上

• 测试故障：利用ChaosMonkey（混乱猴子）技术进行混沌工程，经常测试故障，让您的团队具备故障处理的能力

• ChaosMonkey（混乱猴子）

  • 该技术以在生产环境中随机关闭服务节点而“恶名远扬”，这就是目前熟知的混沌工程的早期雏形。《Chaos Engineering》书中是这样描述的：
    • 混乱猴子的美妙之处就在于此，它能尽可能地将服务节点失效的痛苦的提到最前，同时让所有工程师在构建一个具有足够弹性应对失败的系统上，达成一个一致的目标。
    • 混乱猴子的灵感来自于Netflix几年前搬迁上云的过程，主要是为了解决该阶段暴露的问题，然而，目前不少企业的上云进程依旧缓慢，这种状态下是否还需要混沌工程？随着软件的测试流程越来越成熟且完善，是否有必要花费精力搞混沌工程？如果需要，这一领域有哪些开源工具可供快速部署实践？

• 混沌工程：混沌工程师在分布式系统上镜像实验的学科，目的是建立对系统抵御生产环境中失控条件的能力以及信心。

  • 这句话同样出自《Chaos Engineering》，粗看起来，这一含义有些晦涩难懂。如果简单概况下，周洋对混沌工程的理解是如下四点：
    1. 一种拥抱失败的技术文化
    2. 一套抽象严谨的实践原则
    3. 一种主动防御的稳定性手段
    4. 一个高速发展的技术领域

• 故障转移缓存：由于网络问题和我们系统的变化，服务经常会失败。然而，由于自我修复和负载均衡的保障，它们中的大多数中断是临时的，我们应该找到一个解决方案，使我们的服务在这些故障时服务仍旧可以工作。这就是故障转移缓存的作用，它可以帮助并为我们的应用程序在服务故障时提供必要的数据。

• 重试逻辑：在某些情况下，我们无法缓存数据，或者我们相对其进行更改，但是我们的操作最终都失败了。对于此，我们可以重试我们的操作，因为我们可以预期资源将在一段时间后恢复，或者我们的负载均衡器将请求发送到了健康的实例上。

• 限流器和负载降级：通过流量限制，您可以过滤掉造成流量峰值的服务，或者您可以确保您的应用程序在自动缩放无法满足时，依然不会超载。

• 快速失败原则与独立性：在微服务中通过使用超时来达到快速失败的效果是一种反模式的，你应该避免使用它。取而代之，您可以应用断路器模式，依据操作的成功与失败统计数据决定。

• 断路器：当特定类型的错误在短时间内多次发生时，断路器会被断开。开路的断路器可以防止进一步的请求-就像我们平时所说的电路跳闸一样。断路器通常在一定时间后关闭，在这期间可以为底层服务提供足够的空间来恢复。

2.2.3 TSF与微服务容错设计（续）

• 微服务架构的最大优点之一是用户可以隔离故障，并在当组件单独故障时，进行优雅的服务降级。
• 故障转移缓存通常使用两个不同的过期日期；较短的时间告诉您在正常情况下缓存可以使用的过期时间，而较长的时间可以再服务故障时缓存依旧可用的过期时间。


• 当特定类型的错误在短时间内多次发生时，断路器会被断开。开路的断路器可以防止进一步的请求-就像我们平时所说的电路跳闸一样。断路器通常在一定时间后关闭，在这期间可以为底层服务提供足够的空间来恢复。

• 第一种类型我们以排行榜单为例，比如对王者荣耀的排行榜单数据进行缓存。同一份榜单数据我们设置两份缓存，第一份缓存数据设置为一分钟后过期，第二份数据设置为一个小时后过期。这样在第二分钟到一个小时的时间内，如果存储第一份缓存数据的服务器挂掉后，我们可以直接使用第二份缓存，从而屏蔽故障。
• 第二种类型以电商为例，当电商后台的数据库发生故障时，我们可以设置断路，这样就不会有新的或者重复的请求进入后端的业务系统。
• TSF平台提供服务注册中心，健康检查，负载均衡，失败重试，服务限流，断路器，配置管理等手段实现容错设计，让服务高可用。

2.2.4 TSF与微服务去中心化设计

• 基于目前业界最常见的三种开发方式，提供基于腾讯TSF的演进方案

  

• 原生SpringCloud， SpringBoot，Dubbo应用可以快速改造成TSF的模式，帮助原生应用快速实现去中心化设计。

2.2.4 TSF与微服务去中心化设计（续）

• 架构理念的变化

  • 微服务过程中，架构理念由面向系统结构转为面向服务设计

    

• 首先在架构上由原来的面向系统结构转变为面向服务的设计方式：

  • 在原来的架构中，销售系统的UI和业务逻辑高耦合
  • 在微服务化后，各类业务系统的UI层尽管不同却可以最大化的复用现有的逻辑。

• 业务流程的变化

  

• 业务流程方面也有传统的外包模式业务转变为微服务业务流程，基于业务领域设计原则，提供代码复用能力，让企业更多的关注新业务；

2.2.5 TSF与独立部署

• 微服务TSF平台在发布部署过程中基于部署组维度镜像服务路由，完成不停服的灰度发布。

• TSF同时支持虚拟机部署以及容器部署方式，应用以微服务形式开发，可以再TSF中独立部署。

第三章 微服务架构最佳实践

3.1 微服务调用中的安全架构

3.2 微服务最佳实践-技术架构

3.3 分层微服务架构-组件最佳实践

• 本案例是一个电商的场景，核心业务可以拆分为：在线卖场、订单、会员和购物卡这几个微服务
• 对于通用的能力如安全认证，国际化等组件可以封装到公共基础应用微服务中
• 在公共服务层可以搭建分布式消息队列，全文索引，认证模块等

3.4 TSF的能力图

第四章 微服务的实践案例

4.1 案例介绍

• 背景介绍：2018年某地海关实行关检合并，将原先的出入境检验和海关通关进行合并，统一交由海关侧执行，实现”三个一“模式，即”一次申报“，”一次查验“，”一次放行“

  • 压缩货物通关环节

  • 提升通关效率

  • 降低企业成本

  • 实现信息公开

    

4.1.1 用户痛点和需求

• 痛点和需求：关检合并，不仅仅是简单的系统打通和改造，同时带来的是流程的合并和数据的打通，将出入境检验和海关通关相关的系统数据进行合并和标准化。

• 原有的出入境检验表和海关通关表填制的规范不同，表中各个项的参数或代码不同，需要标准化。

• 底层数据需要打通和整合，同时适应上层业务好服务不同的访问需求。

  

4.1.2 TSF与微服务设计原则

• 痛点和需求：整合原有出入境检验和海关通关相关业务和流程，实现海关业务功能标准化、构件化、服务化
• 快速打通全国通关一体化业务流程，实现流程标准化和闭环。
• 对原有业务实现复用和整合，加快新服务的开发速度，提高海关信息建设对业务改革的支撑能力

4.2 落地方案介绍

• 基于腾讯云TSF分布式框架，实现
  • 分布式应用的快速构建
  • 提供服务注册发现
  • 服务治理，CICD能力
  • 支撑海关原有业务复用和新业务快速构建，并提供统一的权限管理和控制，利用TSF提供的数字化营运能力实现高效运维，保障高效业务的开发和业务可靠稳定。
• TSF打通腾讯云Iaas和PaaS
  • 无缝对接腾讯云人工智能和数据能力平台
  • 为上层业务提供基础技术能力，打通数据壁垒。
• 落地后的系统架构图

4.3微服务化后的优势

• 快速构建分布式应用，提升开发效率
  • 基于腾讯云TSF提供的技术中台能力，快速响应海关关检合并的业务和流程需求，整合原有服务，提供服务注册发现、服务治理，CI/CD等能力，缩短开发周期，节约成本。
• 针对不同用户角色提供服务的权限控制和管理，提高业务的安全性和可控性。
• 高效运维和数字化运营能力
  • 可视化数字运营
  • 丰富的日志检索
  • 业务监控告警能力
  • 快速定位异常，节约运维成本，为业务保驾护航。
• 无缝对接腾讯云技术设施和PaaS层能力，提供更加丰富的基础能力
  • 无缝对接腾讯云IaaS，大数据和人工智能等基础平台能力，实现资源和服务的统一纳管，为上层业务转型提供有效支撑。

思考题

• 微服务设计的原则有哪些？