微服务

典型回答 其实SOA和微服务就是差不多的。 SOA关注的是服务重用，微服务在关注服务重用的同时，也同时关注快速交付； 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线。微服务把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的ESB，服务间轻通信，是比SOA更彻底的拆分。（可以看看这篇文章，我觉得写的挺好的：微服务（Microservice）那点事） 扩展知识 面向服务的架构 面向服务架构（Service-Oriented Architecture，SOA）又称“面向服务的体系结构”，是Gartner于20世纪90年代中期提出的面向服务架构的概念。 面向服务架构，从语义上说，它与面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。与以往的软件开发、架构模式一样，SOA只是一种体系、一种思想，而不是某种具体的软件产品。 这里，我们通过一个例子来解释一下到底什么是SOA？如何做到SOA？ 什么是SOA SOA也可以说是一种是设计原则（模式），那么它包含哪些内容呢？事实上，这方面并没有最标准的答案，多数是遵从著名SOA专家Thomas Erl的归纳： 标准化的服务契约 Standardized service contract 服务的松耦合 Service loose coupling 服务的抽象 Service abstraction 服务的可重用性 Service reusability 服务的自治性 Service autonomy 服务的无状态性 Service statelessness 服务的可发现性 Service discoverability 服务的可组合性 Service composability 这些原则总的来说要达到的目的是：提高软件的重用性，减少开发和维护的成本，最终增加一个公司业务的敏捷度。 既然是面向服务的架构，那么我们就先来定义一个服务， 1 2 3 4 5 6 7 8 9 public interface Echo { String echo(String text); } public class EchoImpl implements Echo { public String echo(String text) { return text; } } 上面这段代码相信有过JavaWeb开发经验的人都不会陌生。就是定义了一个服务的接口和实现。 ...

典型回答 康威定律有各种各样的解读，我觉得比较重要的就是这句话： Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967) 中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。 看看下面的图片（图片是好几年前的了，但是不重要，足够说明白事情了），再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。 简单点说其实就是企业的组织结构决定了业务架构、系统架构。而系统架构的不合理，往往是因为组织架构不合理导致的。 所以很多人说，康威定律如何在半个世纪前就奠定了微服务架构的理论基础 （1）人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理 （2）组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计 （3）如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更加高效。 （4）复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的 康威定律的实践建议 （1） 我们要想尽办法来提升沟通效率，比如使用各种工具。能 2 个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。 （2） 通过 MVP（Minimum Viable Product即最小化可行产品） 的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。 （3） 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。 （4） 做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的 Bezos 有个逗趣的比喻，如果 2 个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是 7，8 人左右（包含前后端测试交互用研等，可能身兼数职）。 ...

https://developer.aliyun.com/article/2764（这篇文章写的很好，好几年前是在我司内网看到的，后来在外网也发布了，我最初理解微服务就是通过这篇文章的） 典型回答 微服务（Microservices）是一种软件架构风格，用于构建复杂的应用程序。它将一个大型的应用程序拆分成一组小型、独立的服务单元，每个服务单元都可以独立部署、运行和扩展。每个微服务都专注于执行一个特定的业务功能，并通过轻量级的通信机制（如HTTP、RPC、MQ等）来相互调用。 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。 比如把一个原来中心化的商城服务，拆分成产品服务、订单服务及用户服务，每一个服务把功能内聚，系统间通过远程调用解耦。实现高内聚低耦合。 并且每一个服务都可以独立的提供子服务。并且他们有自己的应用、自己的存储，是独立的，互不影响的。 而且，拆分后的不同的服务可以使用不同的技术栈，因为它们是独立的。这使得团队可以选择最适合其需求的技术来构建服务。 并且做了服务拆分之后，也能提升迭代速度，至少产品服务的变更不会对订单服务有任何影响。大家可以并行开发，快速迭代。 扩展知识 SOA和微服务 ✅SOA和微服务之间的主要区别是什么？ 微服务和分布式 ✅分布式和微服务的区别是什么？ 微服务和康威定律 ✅什么是康威定律？

典型回答 微服务之间的循环依赖是指在微服务架构中，两个或多个服务相互依赖对方的情况。这里的依赖其实就是互相调用。两个微服务互相调用，A调用B，B又反向调用A，或者A调用B，B调用C，C调用A，这都是循环依赖。 举个例子，假设我们有两个微服务：订单服务（Order Service）和库存服务（Inventory Service）。 订单服务（Order Service）： 当用户下单时，订单服务需要调用库存服务来检查所需商品的库存。 如果库存充足，订单服务会继续处理订单。 库存服务（Inventory Service）： 当库存服务更新库存时，它需要通知订单服务更新订单状态。 为此，库存服务会调用订单服务的一个接口。 这里的循环依赖出现在： 订单服务依赖库存服务来验证库存。 库存服务依赖订单服务来更新订单状态。 我们在做设计的时候应该尽量的避免循环依赖，因为循环依赖会导致以下这些问题： 1、流量放大：因为系统之间存在循环依赖，那么就会导致本来下单系统可能只有100 QPS，但是因为存在循环依赖，就会导致这个QPS被放大，因为100个请求调用到订单服务，订单服务就有100个请求调到库存服务，而库存服务又有100个请求再调到订单服务。就导致订单服务有200的QPS了。无形中被放大了流量。 2、性能问题：因为存在循环依赖，那么服务之间需要等待彼此的响应，就会无形中拖长请求的RT，让接口性能变的更慢。 3、互相影响：如果一个服务出现问题，这个问题可能会通过循环依赖影响到另一个服务。而一个服务中的错误可能通过依赖链传播到其他服务，增加了系统出现级联故障的风险。 4、发布困难：每当一个服务需要更新时，我们需要同时考虑他依赖了谁以及谁依赖了他。一般是被依赖的应用先发布。但是因为系统间存在循环依赖，那么在上一个新的功能的时候需要发布时，就会带来很大的问题，那就是谁先发的问题，而谁先发都会有问题。 主要就是以上这几个问题，所以我们平时需要尽量的避免循环依赖。 扩展知识 如何解决？ 首先，遇到循环依赖的问题，第一件事就是考虑设计的不合理性，一般来说系统会有自己的明确的职责，并且一张架构图中，一个系统一定是有属于他自己的位置的，一个系统又在上游，又在下游，那一定是设计的不合理，所以需要考虑做**重新设计**。 其次，像前面我们提到的例子，库存需要通知订单更新状态，这个过程我们可以把服务调用改成**消息通信**，通过异步消息来解耦调两个系统之间的相互依赖。这样就可以避免互相影响。 另外，比较常用的一种方式，那就是引入一个**共享库**，当出现循环依赖时候，可以考虑将共享部分抽取出来作为一个共享库，然后由各个相关服务共同引用这个库。通过在循环依赖的两个微服务中引用共享库，而不是直接调用对方的接口来操作数据。 上面的共享库，也可以做成一个**共享服务（或者叫中介服务）**，你俩不是互相依赖么，那么干脆我单独搞一个服务出来，你们都直接依赖他而不是做互相依赖。比如我们实际业务中就有一个台账系统，我们会把各个业务流水都写到台账中，所以当我们上游系统之间需要查询数据的时候，就可以直接去台账查，而不需要依赖其他的系统。而台账作为最下游系统，他也不会调用任何其他服务，他最多会提供消息给别的系统。 扩展知识 如何识别循环依赖 要解决循环依赖，首先需要识别出来。那么具体如何识别呢？ 首先，一个一劳永逸的方式，就是有一个明确地架构图，架构图中明确的标注出来各个系统处于什么位置，上游系统都有谁，下游系统都有谁，依赖只能是从上到下的，而不能是从下到上的。有了这样一张图，大家就都知道，我自己的系统处于什么位置，我可以依赖谁，谁可以依赖我了。 如我在网上找的下面这张图，基本上就是一个很明确的从上到下的调用关系。 其实就是可以通过链路追踪来看是否存在循环依赖，当一个调用的trace中，一个应用被调用多次，那么可能就会存在循环依赖的问题。 ✅如何实现应用中的链路追踪？ 还有就是通过各种评审来发现了，比如我们前面提到的，循环依赖会导致发布过程存在谁先发的问题，这个问题在发布评审时是一定可以暴露出来的。 所以，在设计评审，发布评审，TC评审，以及代码评审的时候，需要关注一下是否存在着循环依赖的问题。

典型回答 分布式是把一个集中式系统拆分成多个系统，每一个系统单独对外提供部分功能，整个分布式系统整体对外提供一整套服务。对于访问分布式系统的用户来说，感知上就像访问一台计算机一样。 而分布式架构的具体实现有很多种，这其中包括了C/S架构、P2P架构、SOA架构、微服务架构、Serverless架构等 所以，微服务架构是分布式架构的一种。 扩展知识 C/S架构 C/S架构，就是Client/Server (C/S)架构，在这种架构中，客户端应用程序通过网络连接到一个或多个服务器，并向服务器发送请求以获取服务或数据。服务器负责处理客户端的请求并返回相应的结果。这种架构常见于Web应用程序、数据库系统等。 在传统的C/S模式下，我们想要下载一个20G的电影，我们需要找到一个提供该电影资源的网站，然后连接网站的服务器连续下载。也就是要从文件原始位置开始下载这20G的完整数据。 这种下载方式有什么缺点？ 1、首先这种方式比较依赖服务器的可用性，也就是说，如果服务器挂了，那么就电影的下载不得不终止。 2、如果想要下载电影的人数增多，网站的带宽就会成为瓶颈，就会导致大家下载速度下降，甚至有人无法下载。 3、由于所有资源都通过服务器端输出，别人想要攻击的话也相对方便，只要攻击服务器就可以了。 P2P架构 P2P，是Peer-To-Peer 的简称，翻译成"对等网络"或者"点对点网络"。P2P是一种分布式网络，网络的参与者共享他们所拥有的一部分硬件资源（处理能力、存储能力、网络连接能力、打印机等），这些共享资源需要由网络提供服务和内容，能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源（服务和内容）提供者（Server），又是资源（服务和内容）获取者（Client）。 正是因为C/S模式存在着这些问题，于是P2P就应运而生。 P2P打破了传统的C/S模式，在网络中的每个结点的地位都是对等的。每个结点既充当服务器，为其他结点提供服务，同时也享用其他结点提供的服务。 在P2P模式下，如果有多个人想要下载同一个电影的话，大家就可以不必分别从服务器下载完整的20G的电影。 由于采用了P2P模式，那么每一个用户就可以既充当客户端又可以充当服务器。 如果4个人同时下载20G电影，那么4个人分别各自下载了不一样的部分，然后在下载的同时进行相互传送。 这样大家一边从服务器下载得到数据，一边从别的下载的人那里得到数据，就比单一从服务器下载来得快。 P2P架构具有非中心化、可扩展、高性能、高性价比等优点。 P2P架构在很多方面都有应用，比如我们常用的很多下载软件，如BT、迅雷等。 Serverless架构 Serverless，即无服务架构，是一种将应用程序逻辑交给云服务提供商管理的架构形式。 应用程序以函数的形式运行，通过事件驱动的方式触发。无服务架构将基础设施管理的责任交给云平台，开发人员可以专注于业务逻辑。无服务架构适用于快速开发、弹性扩展和按需计费的场景。 微服务&SOA ✅什么是微服务架构？优势？特点？ ✅SOA和微服务之间的主要区别是什么？

典型回答 Service Mesh是一个比较新的概念，用于解决微服务架构中的一些问题，如服务发现、服务间通信、负载均衡、安全、监控等。 它是一种新型的架构模式，主要思想是将服务之间的通信从服务代码中抽象出来，并在整个应用中提供一种统一的方式进行管理和控制。 Service Mesh代理通常是以sidecar的方式部署在每个服务实例旁边，它们可以拦截和处理来自服务实例的所有网络流量，并提供各种功能，例如负载均衡、故障转移、熔断、限流、安全、监控等。Service Mesh代理可以提供更细粒度的控制和管理，例如在请求级别进行路由和重试，并且可以实时监控和调整服务的行为。 目前比较流行的Service Mesh产品包括Istio、Linkerd、Envoy等。 Service Mesh一般在异构系统中用的比较多，比如一家公司的技术栈比较杂，既有Java、又有C++，还有Python，PHP等 ，通过Service Mesh可以很好的用同一套架构体系将异构语言的程序员整合到一起。 除了前面说的这些，ServiceMesh在实际应用中，还会用来实现以下以下一些功能： 1.rpc转http，http转rpc，用于调用者不支持rpc的情况 2.真实流量压测，将多机的流量转发到一台机器上 3.精准的流量分析，如vip日志，针对某个用户维度的全链路流量跟踪 4.服务健康状态巡检，分析服务的异常，qps，使用率等信息生成报告，并对比历史数据给出异常告警 5.提供数据通路，服务自身可以通过这个通路上报各种非业务性质的内部状态 6.流量拷贝和镜像，把流量拷贝到测试环境，再通过data mesh提供cow与线上数据环境打通，同时不影响线上业务数据。这样排查问题非常方便 7.加速服务通信性能，mesh agnet位于服务机器内，通过lo与服务通信代理流量作为统一流量入口。lo不会过内核协议栈，大幅度降低cpu压力和耗时。而mesh agent自身收发网络流量也可以使用ebpf或者dpdk这样kernel-bypass技术绕过协议栈协议解析，降低cpu压力和耗时。整体通信成本大幅度降低，使用mesh前耗时10-20ms可降低到几ms。

典型回答 CI是Continuous Integration，翻译过来是持续集成，CD可以是Continuous Delivery也可以是Continuous Deployment，翻译过来分别是持续交付和持续部署。 持续集成 持续集成是一种软件开发实践，要求开发者经常集成其变更，方式是将变更合并到主干（trunk）。 持续集成通常通过自动化的构建判定多个变更是否已就绪来实现，也就是说，持续集成可以快速地决定一组变更是否可部署，也可以检测到应用内容的遗漏，包括代码错误、缺失的文件，以及单元测试中潜在的错误。 持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。 持续交付 持续交付（CD）是一种软件开发实践，旨在早期、快速、可靠地发布高质量软件，以满足业务需求。 持续交付构建、测试和部署系统，这些步骤综合在一起以实现及时部署，包括自动化测试、可跟踪性和可扩展性，以及触发维护活动时的预警。 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。 持续部署 持续部署（CD）指的是在持续集成完成后，直接向生产环境部署应用，或者是定期将新功能部署到生产环境的过程。 持续部署通常需要由一组自动化步骤来实现，比如云计算，必要的负载均衡和其它依赖准备工作。 持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。

典型回答 蓝绿部署、金丝雀发布（灰度发布）这些都是软件部署和发布中常用的一些策略和技术，用于实现在生产环境中逐步更新和验证新版本的方式。它们的主要目标是降低部署风险、确保服务稳定性，并实现快速、高效的软件发布。 蓝绿部署是一种在部署新版本时，准备两套完全相同的生产环境，称为蓝环境（Blue Environment）和绿环境（Green Environment）。初始状态下，用户的请求都会被路由到蓝环境，而绿环境处于闲置状态。 当新版本部署完成并测试通过后，将流量切换到绿环境，此时绿环境变为主要的生产环境，而蓝环境则成为备份环境。 当然，在这个切流过程也不是一下100%都要切过来的，也可以先切流一部分，观察一段时间，然后再逐步扩大切流比例，最终完成整体切流。 蓝绿部署的优点是可以实现快速回滚，只需要将流量切回到蓝环境即可。但是他的缺点也比较明显，蓝绿部署有一套闲置环境，这就意味着有一半的机器是不会对外提供服务的，那么就会导致很大的资源浪费。 金丝雀发布，其实就是灰度发布，之所以叫金丝雀发布，是因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气。 与蓝绿部署不同的是，它不需要有一组闲置的服务器，他又叫灰度发布。 在这种方式中，会在整个服务器集群中，挑选一部分机器进行灰度发布，发布会直接对外提供服务，通过给这些已发布的机器引流，来验证服务是否正常。 通过灰度发布，可以在生产环境中测试新版本的稳定性和性能，如果发现问题，可以及时回滚或修复。逐渐增加新版本的流量也可以降低风险，确保系统的稳定性。 一般来说，灰度发布要比蓝绿发布好一些，毕竟他没那么浪费资源，唯一的问题就是回滚不太容易做，需要把已发布应用退回到上一个版本中。 扩展知识 如何快速回滚 有个好的办法，那就是记录基线。应用在发布前，把应用相关的内容，如环境、容器、war包等全部都记录下来，在需要回滚时，直接基于这个基线进行快速部署即可。

典型回答 微服务的拆分是一个复杂的过程，要考虑的因素有很多，其中必须要考虑的有业务领域、团队组织结构、技术架构、部署架构等多个方面。 首先最容易想到的就是按照业务功能进行拆分了。将具有不同功能的模块单独拆分出来作为一个微服务。比如用户服务、订单服务、物流服务等，每一个服务作为微服务部署，单独对外提供自己的能力。 第二点，不可忽视的就是微服务和组织架构之间的关系，按照康威定律来说，应用架构和组织架构应该是一一对应的。所以有的时候微服务的拆分也需要按照组织架构进行拆分，这样更加容易的进行微服务的开发与维护，能够做到最小成本沟通和最快速度的迭代。比如有些公司做了中台，那么就可能有单独的一些中台相关的微服务，如交易服务、店铺服务等。 第三，按照应用类型进行拆分。有一些应用主要处理在线业务，而有些系统专门处理离线业务，那么就可以把他们拆分开，让在线业务和离线业务分离，避免互相影响。 还有，按照技术架构拆分。比如不同的技术栈、使用不同的中间件体系，不同的开发语言等等。这些拆分开有利于独立维护。 除了以上说的这些，还有很多其他的方面，比如按照部署架构等。

典型回答 现在很多公司和团队都在提DevOps，这其实不是个技术，其实是一种开发流程，或者说一种开发文化。**它强调软件开发和IT运维的紧密结合，以实现更快速、更频繁、更可靠的软件交付。**DevOps的核心目标是提高软件交付的速度和质量，缩短软件上线的周期，同时提高应用程序的可靠性和可维护性。 DevOps的出现是为了解决传统软件开发和运维模式中存在的问题，例如开发和运维之间的沟通不畅、软件交付周期过长、人工操作错误率高、应用程序可靠性低等。通过采用DevOps理念和工具，企业可以更快速、更高效地推出新的软件功能，降低软件交付成本，提高客户满意度。 和传统的开发方式上比较的区别是： 以前的开发模式中，开发和运维团队是完全独立开的，开发负责应用开发，运维团队负责打包和发布。出了问题各自看各自的问题。 但是在DevOps的实践中，开发团队和运维团队不再是独立的个体，而是合作伙伴，共同负责整个软件的全生命周期，甚至有些公司直接不要运维团队了，由开发自己做运维。 之所以可以这么做，是因为有很多持续集成、持续交付和持续部署的自动化工具的出现。