之乎者也·的博客

随着技术的发展，配置项管理变得越来越简单，尽管如今它只限于管理业务属性或者配置初始化参数等等，但是当年它可肩负着Spring IOC的光荣使命，风光无限。想当年刚入行的时候还是的天下，那时远没有如今这些丰富的开源组件，一个标准的 Java 程序员就是靠 SSH 这三把刷子打天下，正所谓学好数理化，走遍天下都不怕，但那时候的配置管理是一件让人头疼的事情。早先SSH的配置管理可以说是相当复杂，每个项目的 XML 配置文件大大小小几十个。如果有过Struts1的使用经验就能理解这种痛苦，创建一个Form。

在本文中，我介绍了三个常见的陷阱，我看到客户在整合微服务时踩到了：低估了远程通信的复杂性，忽略了异步性的挑战，忘记了商业交易。通过重试，超时和补偿活动的状态模式引入处理这些情况的功能可以降低微服务基础架构的整体复杂性并增强其弹性。它还有助于：将重要的故障处理和事务行为封装在它所属的位置：在服务本身的上下文中。将故障或超时处理的工作量减少到更小的范围，从而降低整体复杂性。简化服务API，只发布对客户真正重要的故障。改善客户体验，客户可能是其他服务，内部员工，甚至是客户。

本文为大家介绍了微服务架构中的 10 个最佳实践。包含1. 不使用微服务架构、2. 针对失败场景进行处理、3. 构建小型服务、4. 使用轻量级通信协议、5. 服务发现、6. 数据库隔离、7. 实施弹性模式、8. 服务监控以及链路追踪、9. 服务安全性、10.统一日志采集。说了这么多，其实还是希望大家结合自身项目背景，多多思考，不要为了使用微服务而去使用微服务，在已经使用了微服务架构中项目，能够结合上述最佳实践，加上自己对各个服务以及业务上的思考，去解决哪些已存在的问题。这样才算是真正学会了微服务。

熔断机制也是微服务架构中的一种重要的容错处理技术，它借鉴的是电路中的熔断器（Fuse）的设计概念，在电路中，当电流超过阈值的时候，熔断器就会熔断，来保护电路不受损坏，回到软件系统中，熔断器模式就是用于保护系统免受级联故障的影响，提高系统的稳定性和可用性。超时控制是微服务治理中的一项基本技术，通过合理的设置和策略运用，可以有效地提高系统的稳定性和用户体验，而且，超时控制是需要与其他容错机制，比如重试、熔断、降级等结合起来使用的，以构建更加健壮的微服务架构。

尤其在中国这样拥有庞大用户基数的环境下，不用说阿里巴巴、京东这类需要满足双十一大促时每秒几万甚至几十万订单的系统，即使是一些垂直领域的业务系统（如三甲医院的挂号系统）每天也有不小的访问量。使用虚拟化技术或容器化技术，如VMware、Docker等，可以提高硬件资源的利用率，降低系统运行的成本，同时提高系统的弹性和可伸缩性。网络传输的时间通常会影响用户请求的响应时间，选择里用户较近的机房进行部署，或者使用CDN，通常可以缩短请求响应时间，提升系统性能。CAS操作是原子的，可以用于实现无锁化的数据结构。

在使用单体应用程序架构时，客户端（无论是Web还是移动端）通常通过向后端应用程序发起一次REST调用来获取数据。负载均衡器将请求路由至N个相同的应用程序实例中的一个。随后，应用程序会查询各种数据库表，并将响应返回给客户端。然而，在微服务架构中，单体应用程序被拆分成多个微服务。若直接将所有微服务对外暴露，可能会导致安全方面的各种问题，同时也会增加内外耦合的严重性。客户端可以直接向每个微服务发送请求，其问题主要如下：• 客户端需求和每个微服务暴露的细粒度 API 不匹配。

在这篇文章中，我将演示在决定使用单体架构、微服务架构和无服务器架构时的权衡的简化心智模型。目标是突显每种风格的固有优势和缺陷，并提供关于何时选择哪种架构风格的指导。单体架构对于小团队或项目来说是理想的入门架构。它简单易上手，通常在需要超过一个团队的规模之前能够提供很多收益。在构建单体架构时，务必从模块化开始，即使可能会增加样板代码。这意味着构建组件并在层之间保持严格的逻辑分离（更多详见Clean Architecture）。

JUnit是Java中最为流行的单元测试框架之一，它提供了注解和断言来简化测试的编写。Mockito是一个用于Java开发的Mock框架，用于创建和配置Mock对象，以支持单元测试。集成测试旨在确保微服务的各个组件在一起协同工作。在Spring Boot中，通常使用注解来进行集成测试。

在Spring Cloud微服务开发中，选择HTTP协议作为交互方式的主要原因包括通用性、简单性、浏览器支持、跨域通信能力、内容类型多样性、 丰富的状态码和响应头、性能和扩展性、与RESTful风格的兼容性、生态支持和灵活性与可扩展性。这些特点使得HTTP协议成为微服务之间通信的理想选择，能够满足各种业务需求，并提高系统的可用性和伸缩性。

曾经设计的一个供应链系统中，存在商品、销售订单、采购这三个服务，它们的主数据的部分结构如下所示。在设计这个供应链系统时，我们需要满足以下两个需求：根据商品的型号/分类/生成年份/编码等查找订单；根据商品的型号/分类/生成年份/编码等查找采购订单。初期的方案是这样设计的：严格按照的微服务划分原则将商品相关的职责存放在商品系统中。因此，在查询订单与采购单时，如果查询字段包含商品字段，需要按照如下顺序进行查询。先根据商品字段调用商品的服务，然后返回匹配的商品信息；

在分布式服务的场景下，业务服务都将进行拆分，不同服务之前都会相互调用，如何做好异常处理是比较关键的，可以让业务人员在页面使用系统报错后，很清楚的看到服务报错的原因，而不是返回代码级别的异常报错，比如NullException、IllegalArgumentException、FeignExecption等异常报错，这样就会让非技术人员看到了一头雾水，从而很降低用户的体验感。@Slf4j@Bean/*** 重新实现feign的异常处理，捕捉restful接口返回的json格式的异常信息*/

本文既有理论知识，又有实用信息：我们将学习每一种具体的模式，为什么以及应该在什么地方使用；然后，我们将看下应用了这些模式的参考架构；接下来，我们将综合运用新学到的模式设计我们的架构；最后，我们将确定选用什么技术实现架构。本文将介绍微服务架构设计中的设计模式、原则及最佳实践。我们将使用适当的架构设计模式和技术。通过本文，你将了解到如何利用微服务分布式架构设计一个高可用、高可扩展、低延迟且对网络故障有弹性的系统，以处理数以百万计的请求。

简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。内部的微服务对外部访问来说位置透明，外部应用只需和网关交互统一拦截接口服务，实现安全，日志，限流熔断等需求从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：

随着微服务架构逐渐成为主流，开发者们开始将多个服务组合在一起来构建应用程序。微服务架构强调服务的独立性和自主性，使得服务间的通信变得复杂。Service Mesh在这种背景下应运而生，为服务间的通信提供了新的解决方案。Service Mesh定义如下：Service Mesh是在基础架构层处理服务间的通讯，实现云原生复杂的服务拓扑情况下的可靠请求分发。在实现上是一组轻量化的网络代理，这些代理透明的部署在应用周边，无需应用感知。

过去的10-20年企业面临着一系列具有挑战性的情况，包括过多的异构和分散的应用程序平台（如 ERP、互联网门户）以及大量孤立的单体定制应用程序，缺乏统一的企业视图。业务流程分散在多个产品上，数据重复且不一致。当与刚性架构相结合时，交互变得效率低下，处理速度缓慢。当复杂的信息交互分布在不同的 IT 系统中时，这些问题就会加剧。最重要的是，提高竞争力和快速变化需要业务敏捷性，同时保持较低的拥有成本。借助面向服务的架构 (SOA) 计划，企业可以简化和简化复杂的交互，使他们能够专注于盈利增长。

在微服务中，一个逻辑上原子操作可以经常跨越多个微服务。即使是单片系统也可能使用多个数据库或消息传递解决方案。使用多个独立的数据存储解决方案，如果其中一个分布式流程参与者出现故障，我们就会面临数据不一致的风险 - 例如在未下订单的情况下向客户收费或未通知客户订单成功。在本文中，我想分享一些我为使微服务之间的数据最终保持一致而学到的技术。为什么实现这一目标如此具有挑战性？只要我们有多个存储数据的地方（不在单个数据库中），就不能自动解决一致性问题，工程师在设计系统时需要注意一致性。

领域驱动设计，Domain-Driven Design，简称 DDD，是一种软件设计方法论，它强调以业务领域为核心来构建软件架构，DDD 由 Eric Evans 在其 2003 年的同名书籍中首次提出并进行了系统性地阐述，自此在软件研发领域中产生了广泛的影响。DDD 的出现是为了解决复杂业务领域的软件建模问题，随着企业应用的复杂性和规模的不断增长，传统的以数据为中心或者以技术为中心的设计方法往往难以应对，DDD 通过引入领域模型、通用语言、限界上下文等概念，帮助开发团队更好地理解和应对业务领域的复杂性。

从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）他们都是使用分而治之这项成熟的传统技术来应对大型系统的复杂性。自 2010 年开始，这些技术被证实无法继续应对 Web 级应用或者现代大型企业级应用的复杂性。

现在对于一个后端开发工程师来说，微服务，DDD都是挂在嘴边的东西，感觉大家接触到多，也了解的多。然而，个人对微服务架构的理解却如同我小时候读《三国演义》，随着年龄和经验的增长，感受也各不相同。微服务对于开发人员而言，如同千面镜，每个人看到的风景都独具特色。基于此，我想结合自己的业务实践，分享一下在微服务架构实践过程中的心路历程。在笔者看来，微服务架构并没有一个准确的定义，但他会有很多特征，通过描述他的特征用来把控它是什么。

软件在开发的时候经常会提到一个些架构的概念，比如说单体架构、垂直应用架构、分布式架构、SOA架构、微服务架构，本文简单介绍不同架构的区别以及各自的优劣势，以便大家区分开。

著名软件大师Chris Richardson 曾一针见血地指出：“微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”种种复杂局面便催生了服务间通信层的出现，这个层既不会与应用程序的代码耦合，又能捕捉到底层环境高度动态的特点，让业务开发者只关注自己的业务代码，并将应用云化后带来的诸多问题以不侵入业务代码的方式提供给开发者。这个服务间通信层就是 Service Mesh。

本文介绍了同步微服务交互面临的各种挑战。这种方法在某些情况下是适用的。不过，还有另一种微服务通信方式。下一篇文章将讨论异步微服务交互。

服务降级是指在面对系统故障、资源限制或高并发等情况下，通过减少或关闭某些功能或服务的使用，以保证核心功能的可用性和稳定性。通过服务降级，可以避免整个系统的崩溃或性能下降，保证核心业务正常运作，提高用户体验。举个大家都知道的例子，天猫双11活动时，为了保证平台与商家的交易稳定，关闭了很多数据的导出功能，关闭了区域预售功能，关闭了客服留言功能，查询历史订单搜不到对应订单等等，这都是服务降级。服务等级定义 SLA（Service Level Agreement）是判定压测是否异常的重要依据。

今天我们来聊聊缓存这个话题，看看在微服务环境下如何设计有效的多级缓存架构。主要涉及三方面内容：Web 应用的客户端缓存；应用层静态资源缓存；服务层多级缓存。首先，咱们先讲解微服务架构的多级缓存设计。提到缓存，想必每一位软件工程师都不陌生，它是目前架构设计中提高性能最直接的方式。这里我们举个例子：Redis 缓存假设应用程序将原始数据存储在 MySQL 数据库中。

上面何小锋的讲解，我理解是整合在动态代理上，如果真熔断了至少省去序列化到编码的那部分时间，但是按照大部分人的理解惯性以及一些框架的设计（我至少翻了两个），是在网络准备传输之前处加上的。熔断器不在静默期，并且慢调用的比例大于设置的阈值，则接下来的熔断周期内对资源的访问会自动地被熔断。熔断说的是服务之间的调用能实现自我恢复的状态，终有停止熔断的时刻，是非持续的；服务治理中的熔断机制，指的是在发起服务调用的时候，如果被调用方返回的错误率超过一定的闻值，那么后续的请求将不会真正发起请求，而是在调用方直接返回错误。

在当今迅猛发展的软件开发领域，微服务架构已经成为构建灵活、可扩展系统的关键方法之一。本文将带领读者深入了解微服务架构的核心思想，并介绍构建这一架构所需的常用组件，为各位开发者提供全面的指导和洞察力。

在微服务架构风格中，微服务通常按照单一职责原则（SRP）设计，作为一个单独部署的软件单元，专注于做一件事情。我们作为开发人员往往倾向于尽可能将服务设计得更小，却没有考虑为什么要这样做！关于服务颗粒度的主观性，即什么是单一职责，是我们作为开发人员在微服务颗粒度方面犯错的地方。为了克服开发团队在确定微服务大小时面临的困境，理解颗粒度的驱动因素是至关重要的。

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。在腾讯视频的DDD重构案例中，在老的微服务架构中，存在分层不明确，下层服务过于理解业务逻辑，存在下层调用上层的问题，出现了代码耦合严重，调用关系混乱的 “微服务小泥球”。如果是 数据驱动原则/界面驱动原则 ，那么，是一上来就定义数据库表结构，就去调整领域逻辑代码。

Sentinel是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性。官网：https://github.com/alibaba/Sentinel/wiki2012年，Sentinel诞生于阿里巴巴，其主要目标是流量控制。2013-2017年，Sentinel迅速发展，并成为阿里巴巴所有微服务的基本组成部分。它已在6000多个应用程序中使用，涵盖了几乎所有核心电子商务场景。2018年，Sentinel演变为一个开源项目。2020年，Sentinel Golang发布。

相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地。

Sentinel的核心原理是用户可以定义各类资源（资源可以是本地的一个接口，或者远程的某个依赖），并在资源上设置各种规则（比如限流规则），在访问某个资源时，Sentinel组件会检查这些规则是否满足，在不满足的情况下会抛出特定的异常。此外，标准架构并非固定不变的体系，对于新技术的引入，我们提供了标准化的流程，确保技术体系能够持续迭代；在微服务标准架构的选型过程中，我们综合了各开源项目的实际情况和业界的主流技术方案，将各个领域中的技术选型进行了统一，每个领域的技术选型原则上均不超过1种；首先是指标计算问题。

在逻辑和数据扩展之外，Uber的很多团队都推出了自己适合自己领域的扩展模式。例如，与我们的展示架构绑定的很多集成都使用了基于DAG的任务执行逻辑。

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。在腾讯视频的DDD重构案例中，在老的微服务架构中，存在分层不明确，下层服务过于理解业务逻辑，存在下层调用上层的问题，出现了代码耦合严重，调用关系混乱的 “微服务小泥球”。如果是 数据驱动原则/界面驱动原则 ，那么，是一上来就定义数据库表结构，就去调整领域逻辑代码。

优雅停止的总结：优雅停止是当微服务快要下线的时候，先从注册中心进行去注销，然后把接收到的RPC调用消息，处理完毕后，再彻底关闭。通过优雅停机，可以有效地防止升级期间，发送到老节点的呼损。优雅启动，当微服务实例真正完成启动，甚至完成预热之后，真正具备处理 RPC 请求能力的时候，再将实例自己注册到注册中心。这个中间，有一定的时间周期，所以，如果要做到应用无损升级， 需要在发出通知之后，隔一段时间，再把服务实例正式关闭。当然，如果希望通过重试的机制，让RPC零呼损，那么要保证升级的时候，还有健康的实例可用。

除了监控功能，我们还可以利用Prometheus或Grafana的报警功能，为我们的指标设置告警规则和通知渠道，当指标达到某些条件时，例如线程平均耗时过长，大量线程执行异常，大量任务被拒绝时，及时收到告警通知，例如钉钉、邮件等。的报警功能，为你的指标数据设置告警规则和通知渠道，当指标达到某些条件时，及时收到告警通知，例如钉钉、邮件等。实际上, 大部分的线程都是 混合型线程， 很难准确的去估算 线程等待时间 和 线程CPU时间. 所以，一种有效的办法是：根据 监控指标，动态的标准 线程池的线程数。

网关是微服务架构中的一个关键的角色，用来保护、增强和控制对于微服务的访问。网关是一个处于应用程序或服务之前的系统，用来管理授权、访问控制和流量限制等，这样微服务就会被微服务网关保护起来，对所有的调用者透明。因此，隐藏在微服务网关后面的业务系统就可以更加专注于业务本身。同时，微服务网关还可以为服务提供和沉淀更多附加功能。

定义preStop钩子接口优先执行核心的下线逻辑，比如这里的 微服务实例下线具体如何操作呢？step1：在SpringBoot应用中，定义WEB接口，实现核心线下逻辑step2：在 pod的preStop钩子接口的设置上，设置为SpringBoot应用的下线钩子链接step1： 在SpringBoot应用中，定义WEB接口，实现核心线下逻辑step2：在 pod的preStop钩子接口的设置上，设置为SpringBoot应用下线钩子链接。

Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。Buoyant 公司的 CEO Willian Morgan 在他的这篇文章中解释了什么是 Service Mesh，为什么云原生应用需要 Service Mesh。下面是 Willian Morgan 对 Service Mesh 的解释。翻译成中文是：服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。

微服务是最近非常火热的新概念，大家都在追，也都觉得很对，但是似乎没有很充足的理论基础说明这是正确的，给人的感觉是 不明觉厉。前段时间看了Mike Amundsen《远距离条件下的康威定律——分布式世界中实现团队构建》（是Design RESTful API的作者）在InfoQ上的一个分享，觉得很有帮助，结合自己的一些思考，整理了该演讲的内容。

随着架构设计的发展，微服务架构可以说是目前架构领域炙手可热的设计理念。在公司，笔者也一直在负责系统的服务化设计和开发工作。今天就来谈谈微服务落地实践中的一些问题。希望对微服务设计无从下手的朋友，起到一些参考作用；另外也希望把自己的观点分享出来，期待与大家一起交流，能够认识到不足之处。