很早很早之前，我对于架构的概念一点都不理解，依稀记得，架构（ architecture）这个词，来自于建筑领域。　　这对于我这个没写过几行代码的人来说，瞬间就有了一种“不明觉厉”的崇拜感。　　架构，感觉好厉害的样子，从名称上来说，好像是设计根骨，设计底层，设计最核心的东西的人。　　架构师，一定很NB，我什么时候能成为架构师呢？　　后来懂了一点点代码，去写增删改查，更是体会不出来架构的概念，不就是Sql语句吗？明明DBA更厉害啊，做各种的慢Sql优化，所有的Sql都要让DBA审核，DBA对于Mysql，或者是Oracle的各种性能调忧很厉害，而熟悉业务的开发人员又常常能写出几万行的SQL语句。　　我看到这些头都要炸了好么？　　所以，倒底什么是架构？整个系统只有一个WEB，Spring MVC+Spring+Hibernate搞定一切，开始做需求分析，实际上就是设计表结构而已，剩下的就是查查查，改改改，删删删。　　直到某天，我知道一个词，缓存。　　缓存这玩意儿，在很早之前学习各种基础课程的时候，了解过一些，一级缓存，二级缓存什么的，LRU我好像也懂一点点，但是，在系统里，缓存算是什么？　　在公司里，那个架构师，画了一张图，告诉我们，这台机器上，放了一个Memcache，然而我们都不懂，他只解释了一句，这个Memcache是缓存。　　我的第一个困惑就是，所有的请求都要再次转发到另一台机器上，把数据取出来，单个请求可能不算什么，每天有几十万次请求，这中间的损耗不大么，为什么不把Memcache放到本地机器上呢？　　他没解释，只告诉我说，不大，Memcache就是要放在另一台机器。　　在当时，我不清楚内网和外网的差别，也不清楚访问Memcache的请求倒底是需要多少MS，更不理解，把Memcache放在和业务层一台机器，或者是分开放的差别倒底是什么。　　但这个问题一直困惑着我，简单来说，这其实算是一点点架构师要做的事情的萌芽，一个系统中，如果拆解出来了很多模块，倒底应该部署在哪些机器上？架构师会解决这些问题。　　后来，到了搜狐之后，我突然间发现了我之前学到的东西，在搜狐的技术大神面前，直接被轰成渣。　　负载均衡是什么？热备又是什么？　　穿透DB是什么意思？怎么我取数据库里取一个值，数据库里没有，这种空数据的请求会把DB打跨？我还要把这些为Null的请求单独缓存起来？　　本地缓存做为一级缓存，Memcache做二级缓存？　　“对缓存来说，最关键的设计就在于失效策略是什么。”大神镇定的看着我。　　我很惶恐，感觉能把失效策略设计出来，很不容易。　　不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。　　对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。　　五年成为阿里技术专家，架构师需要懂哪些技术？　　这算不算架构中的一部分，根据不同的应用需要，去设计不同的策略，同时把这些场景规范化，成为一整个团队都要去遵循的标准？　　我不知道，我只知道，能Hold住团队里所有人的那个人，技术一定非常NB，团队里的每一个人，都会质疑，如果你Hold不住全场，怎么能推行下去？　　当时近30的技术团队里，每一个都是神一样的存在啊，谁能Hold住30多个神。　　而且，原来不应该把所有的代码放到一个WEB里，原来分布式是这么回事儿，原来一个系统，是由多个子系统构成的，原来还要分层，原来封装和抽象是这么个意思。　　WEB层是一层，通常可以通过LVS部署两台到三台，或者是更多的，Service一层用来处理业务逻辑，缓存层用来扛并发，一定要藏在Service里面，Controller调用Service的时候，并不需要知道，数据倒底从哪来的，每一个Service使用什么样的缓存策略，完全不需要Controller层知道，持久化，对，对于大型应用来讲，Mysql只能用做是持久化，Mysql的单条访问速度并不查，只是在并发能力太差，扛不住。但是，有可能数据量过亿啊？　　过亿怎么办？是用分库，还是分表？读写分离要不要做？一台服务挂一台数据库，哪些数据库应该放在一个实例里，哪些应该单独拆出去？每台服务器的配置是什么？　　我大概知道一点点，架构师要做哪些事情，他就是要把这些大的骨架定好，然后我们去填充里面的内容。如果骨架定歪了，其余团队必然跟着歪。　　这时候有了一系列的问题，第一个，Controller和Service之间，Service和Service之间，应该通过什么调用？　　RMI，这是惟一的选择。用thrift，或者是ProtocolBuffer，或者是Rest实现的RPC？　　这是架构师要考虑的事情，如果是用RMI，我们是要自己实现，还是要找找是否有好用的开源的框架，在其他的系统里被证明了是有用的？　　大神们花了两周的时间，对当时流行的开源框架过了一遍，最终选定了Tuscany，到现在我都觉得设计精美，完暴Dubbo的东西，真的是一点都不想切到Dubbo上去，毕竟“曾经沧海难为水，除却巫山不是云”。　　直到最近几年微服务兴起的时候，我还是同样的目瞪口呆，这跟2009年搜狐当时做白社会的架构比起来，优势倒底在哪里？差别好像没有那么大啊，而且Tuscany实现的更完美，只是使用的时候要有更强的约束，因为Tuscany太强大了~强大到有一点点重，必须要做简化，而且，Tuscany的开发团队不怎么维护了，白社会当时做的东西，还是大神花了两周的业余时间写了一个Scallop，增加了Tuscany的负载均衡的功能。　　但是，倒底用什么，不用什么呢？除了Tuscany，还讨论过要不要用Hadoop，要不要用ActiveMQ，要不要用Erlang。　　每一个技术框架的选择，都经过讨论，验证，测试，最终在全团队里推行。　　这是否也是架构师的职责？这个架构师太厉害了，他需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案，他需要去猜测Facebook怎么解决问题的，Twitter怎么解决问题的，Google怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。　　他需要精通分布式，Nginx或者是F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计，他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。　　这样的架构师，还要肩负着一个重大的使命，修复开源软件的Bug。　　在很早之前，我一直误以为开源软件是很厉害的很NB的东西，我一直以为这是完美的，很久很久之后，才明白，所谓的完美，都是用血和泪塑造而来的。　　不经过各种各样的验证，环境，使用的测试，很难达到一个上线标准的稳定，即便是上线了，也有可能会出现之前完全预料不到的问题。　　可是，如果你选择了这个框架，出了问题，谁去解决？　　架构师，他要开源码，理解这些开源框架的思路，然后去找有可能产生问题的地方，再去修复他。　　我一直都觉得，能看懂别人写的代码的人，都是神。　　某段时间我去看一个heritrix,看的我神清气爽，各种层出不穷的继承，各种抽象类，连着三天我欲仙欲死，更加坚定了我死也不要，也不允许其他人在项目里使用继承的决心。　　但是Heritrix从外表看起来特别牛，他的抓取策略也很NB，用的分布式抓取的解决方案非常轻巧。可是我我实在是不想再去读一次了，在当时不读不行，资料太少。　　那么，一个架构师，要对这些源码都了解么？又或者是，他必须具备，需要他去读源码，他就必须读源码，而且去优化的能力？这大概比提前懂源码，更神奇。　　因为是有时间要求的啊，简单来讲，他需要在一个有效的时间内，去弄懂所有的底层的东西，说句实在话，当有同事嘲笑我都没有完整的看过TCP/IP协议详解的时候，我真的是无话可说的。　　对于特别底层的东西，我确实了解的不够多，可是架构师们不一样。　　有了这些，就可以称之为架构师了么？　　架构师需要懂业务么？是不是就可以每天看技术，写底层框架（比如我们原来在搜狐用到的DAL，数据访问层，用起来简直是神器的东西）。　　没有不懂业务的架构师，所有的架构，都依赖于业务。所有的架构师，也必须要去写业务代码，不把自己设计的东西，用在真正的项目里，恐怕他们自己都不会知道，这种架构设计的合理性在哪里。　　在某团购公司上市之前，他们的CTO拿出来了他们的架构图给我看，在给我看之前，所有的技术术语都一样，但是当我认真看了架构图之后，我的困惑。。。。　　为什么Memcache要放在Controller层被调用？ 不应该是放到Service层吗？　　怎么会出现你说的，一个Serivce负责维护的数据，也有可能被另外的Service去更改的情况？每一个Service对数据的操作，必须是独立的啊，除了这个Service，其他的任何服务都决不允许直接更改DB啊。　　而且，怎么Service拆分了，DB不拆分呢？这样的话，压力大的DB会把全站拖跨的啊。　　那张架构图我看到之后，感觉自己的认知被突破了，原来可以这么做，原来同样的，类似的技术选型，可以做出来如此艰难的东西？　　就在我以为这其实就差不多是架构师的全部的时候。　　在最近一段时间，我突然间发现了一个问题。　　为什么有的人代码写的这么烂，很多写死的代码，一点儿全日制灵活性都没有，更没有规范，完全就是堆压。　　为什么有的人根本不知道怎么去抽象，并不清楚怎么样积累成公共组件，为什么他们改一个问题，通常会引出更多的问题？　　为什么他们的代码里的实现方案，让人看完之后恨的牙痒痒，想改又完全不能改，毕竟，正常工作的代码才是好代码？　　很大程度上是因为，很多程序员，不懂的代码的扩展性，不会面向未来编程。　　怎么叫做面向未来编程？　　一个好的工程师，在听到需求的时候，可以根据自己的业务能力，判断出来这些需求中，哪些是有可能变化的，哪些是不太可能变化的。　　针对这些变化的内容，在编写的过程中，不会写死，而反复确认不可能会变化的需求，会写的简单一些，防止过度设计引起的复杂度。　　简单说，当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。　　在完成设计之后，他会很清楚的知道 ，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。　　而且会拿着自己的架构体系跟PM沟通，讲清楚。　　什么样的变化是支持的？短信通道是有可能变化的，而调用短信通道的地方可能会有点多，所以我必须把短信通道抽象，并封装在一个公共接口，如果需要更换短信通道，我可能只需要更改一个配置文件就好了。　　那么什么样的变化是不支持的？我不需要不停机就更换短信通道的功能，除非你在后台系统中提前配置好，或者是有明确的需要，我做出这么一个东西出来。往往在前期，不会用到。　　为什么？　　在创业初期，短信通道往往用于用户注册，一旦出问题，就是生死问题，必须要有一个备份，运营商一怒封掉你的通道，很常见。　　而重启一次服务，在创业前期，往往没有那么严重。　　所以，这些技能，是不是也应该归纳到架构师的职责里去？　　架构师从开始就要考虑选型，从语言开始，从业务开始，要对这个领域里的开源框架熟悉，了解，要能解决疑难问题，要懂安全，要会备份，要学会面向未来编程，还需要什么？　　还需要DevOPS.　　在持续集成的年代，在服务器规模越来越大，在云服务器的年代，在异地存储，冗灾，在全球化越来越快的年代。　　运维的重要性已经到了一个很核心的程度了。弹性伸缩，自动扩容，灰度发布等等等概念，要求，都在冲击着架构师这个概念的定义。　　如果说之前的架构师，更多的是在系统开发前，现在越来越偏于系统上线后。　　还包括数据分析，日志分析，等等等等，对了，还没有提到Nosql DB，实时搜索，知识库，算法这一系列的东西。　　每一个领域都在细分，每一个概念都在深化。　　简单说，架构师确实和语言无关，但是又绝对和语言有关系。　　你可以说，架构师就是在做选型，但是只会做选型，肯定做不出架构师。　　Java更需要架构师，因为他本身就是各种开源框架，不对这些框架了解的清清楚楚，你很难做出一个好的选择，而一旦架构被固定，实际业务人员的开发，又会变的简单很多。　　说到了现在，我有没有讲清楚架构师是什么？　　而你，还想要做架构师吗。　　五年成为阿里技术专家，架构师需要懂哪些技术？

云原生时代背景下，快节奏的软件驱动型市场不断驱使着越来越多的企业寻求加速创新，改变原有的应用构建方式，转而尝试新的设计、构建和使用应用的方式 -- 即我们常说的“云原生应用”。它可谓是充分利用了云原生技术，最大程度释放了云原生时代的技术红利。为了让更多开发者了解到云原生应用，更好地拥抱云原生时代，本次线上 Meetup 我们邀请到了微软最有价值专家、开源爱好者、.NET 后端开发工程师 - 李帅，Apache Dubbo Committer、阿里云 MVP - 张天，Apache SkyWalking PMC 成员、Erda 微服务平台负责人 - 刘浩杨，Erda DevOps 平台负责人 - 郑嘉涛为大家带来详细解读，邀你共聊《云原生应用开发的探索与实践》。活动亮点抢先看什么是云原生应用？云原生应用相比较于传统应用的优势？如何成功实现云原生应用开发？一众技术专家的实践心得精彩好礼相赠······更多精彩，尽在 1 月 25 日活动直播间等你来～还有可能获取精美好礼哦！活动时间2021 年 1 月 25 日 14:00 - 17:05观看地址 - B 站嘉宾 & 议题介绍《探索云原生可观测性框架 OpenTelemetry》李帅.NET 后端开发工程师, 开源爱好者, 微软最有价值专家OpenTelemetry 是一个开源的可观测性框架, 它是云原生时代可观测性的新标准，在本次分享中, 我会带大家全面认识 OpenTelemetry, 项目的来世今生, 它是如何工作的, 项目架构, 以及它如何帮助开发人员在分布式系统中实现满足其业务目标所需的可观测性。《Dubbo Ecosystem 中的高性能网关和多语言解决方案 —— Pixiu》张天Apache Dubbo PMC 成员、阿里云 MVP以异构多语言服务接入已有 Dubbo 集群场景为切入点，介绍 Dubbo 生态中网关项目 Pixiu。Pixiu 作为代理网关或 sidecar 赋能服务轻量级接入 Dubbo 集群的能力，作为强依赖特定框架的另一种方案。此外，Pixiu 还提供 HTTP、Dubbo2、Triple 和 GRPC 等多协议转换和流量治理能力，是 proxy service mesh 方向的一种探索。《聊聊微服务的全栈可观测性》刘浩杨Erda 微服务平台负责人，Apache SkyWalking PMC 成员，开源爱好者在云原生架构下，基于 DevOps、微服务、容器化等云原生的能力，可以帮助业务团队快速、持续、可靠和规模化地交付系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战。在此背景下，对分布式系统的“可观测性”应运而生，可观察性提供了一套理念来监控、诊断云原生微服务系统。和监控相比，可观察性从单一的度量扩展为 Metrics、Tracing、Logging 三大支柱，Erda 中的 APM 系统也在逐渐演进为以可观察性分析诊断为核心的微服务观测平台，本次主题将会解读 Erda 在微服务观测系统上的探索和实践。《终极套娃：如何利用 Erda 构建部署 Erda？》郑嘉涛开源爱好者，Erda DevOps 平台负责人我一直相信“dogfooding”的软件会有更棒的使用体验、更强更旺盛的生命力，同时也更具有说服力。以 Erda 自身为例，本次我将分享如何在 Erda 上进行软件开发和协作，持续构建出可用的制品；如何进行自动化测试，以及如何最终交付产品。详细议程

前言参考资料：《Spring Microservices in Action》《Spring Cloud Alibaba 微服务原理与实战》《B站 尚硅谷 SpringCloud 框架开发教程 周阳》注册中心用来集中管理微服务，实现服务的注册，发现，检查等功能；1. 服务发现基础知识1.1 注册中心与服务发现的联系注册中心是用来集中管理微服务，实现服务的注册，发现，检查等功能；服务 A 与服务 B 注册进注册中心 C，形成服务注册表（表里登记了服务 A 和服务 B 的地址等相关信息）。当 A 服务想要访问 B 服务时，可以通过注册中心 C 的服务发现机制，获取服务注册表进而找到服务 B；1.2 使用 DNS 与负载均衡器发现服务的弊端这种模型适用于在企业数据中心内部运行的应用程序，以及在一组静态服务器上运行少量服务的情况；对基于云的微服务应用程序不使用，理由如下：单点故障：如果负载均衡器出现故障，那么依赖它的每个应用程序都会出现故障；有限的水平可伸缩性：大多数商业负载均衡器使用热插拔模型实现冗余，只能使用单个服务器来处理负载，跨多个服务器水平伸缩负载均衡基础设施的能力有限；静态管理：大多数传统的负载均衡器不是为快速注册和注销服务设计的。它们使用集中式数据库来存储规则的路由；复杂：需要手动定义和部署服务的映射规则；1.3 云中的服务发现应该具备的特点高可用：如果一个节点变得不可用，集群中的其他节点应该能够接管工作；点对点：每个节点共享服务实例的状态；负载均衡：在所有服务实例之间动态地对请求进行负载均衡；有弹性：务发现的客户端应该在本地缓存服务信息；容错：需要检测出服务实例什么时候是不健康的，并从可以接收客户端请求的可用服务列表中移除该实例；1.4 服务发现架构服务发现需要关注的四个概念：服务注册；服务地址的客户端查找；信息共享；健康监测；这种方法很脆弱，因为服务客户端完全依赖于服务发现引擎来查找和调用服务；1.5 服务治理的概念在传统的 RPC 远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系；可以实现：服务调用、负载均衡、容错等，实现服务发现与注册；1.6 服务注册的概念在服务注册与发现中，有一个注册中心；当服务器启动的时候，会把当前自己服务器的信息。如：服务地址通讯地址等以别名方式注册到注册中心上；另一方（消费者|服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地 RPC 调用 ；1.7 RPC 远程调用框架核心设计思想在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系（服务治理概念）；在任何RPC 远程框架中，都会有一个注册中心，用于存放服务地址相关信息（接口地址）；1.8 Eureka 与 Dubbo 的系统架构对比图1.9 注册中心的 CAP 理论CAP 含义：C：Consistency 强一致性：注册一个服务，集群下多节点必须全部注册成功后才能进行访问和使用；master节点挂掉了需要等待重新选举成功后才能使用，选举期间服务不可用； (所有节点在同一时间具有相同的服务)；A：Availability 可用性：注册一个服务，只要有一个节点注册成功就可以对外提供访问；master节点挂了也可以正常使用； (保证每个请求不管成功或者失败都有响应)；P：Partition tolerance 分区容错性：把服务注册到每个节点，增强容错机制 (系统中任意信息的丢失或失败不会影响系统的继续运作)；CAP 理论关注粒度是数据，而不是整体系统设计的策略；CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求；因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：CA 原则：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大；CP 原则：满足一致性，分区容忍性的系统，通常性能不是特别高；AP 原则：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些；经典CAP图：1.10 AP 架构和 CP 架构AP 架构：当网络分区出现后，为了保证可用性，系统 B 可以返回旧值，保证系统的可用性；结论：违背了一致性 C 的要求，只满足可用性和分区容错，即 AP；CP 架构：当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性；结论：违背了可用性 A 的要求，只满足一致性和分区容错，即 CP；1.10 目前几种流行的注册中心对比基础对比：名称厂商CAP 模型控制台管理对外暴露接口社区活跃度EurekaNetflixAP支持HTTP低（2.x 版本闭源）NacosAlibabaAP+CP 可切换支持HTTP/DNS/UDP高ZookeeperApacheCP不支持TCP 客户端中ConsulHashiCorpCP支持HTTP/DNS高功能与支持性对比：比较项EurekaNacosZookeeperConsulCoreDNS健康检查Client BeatTCP/HTTP/MySQL/Client BeatClient BeatTCP/HTTP/gRPC/CMD/负载均衡Ribbon权重/DSL/metadata/CMDB/FabioRR雪崩保护支持支持///自动注销实例支持支持支持//监听支持支持支持支持支持/多数据中心支持支持/支持/跨注册中心/支持/支持/Spring Colud 集成支持支持支持支持/Dubbo 集成/支持支持支持/kubernates 集成/支持/支持支持2. EurekaEureka 是 Netflix 开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在 AWS 域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的；Spring Cloud 将它集成在其子项目 spring-cloud-netflix 中，以实现 Spring Cloud 的服务发现功能；点击跳转：微服务架构 | 3.1 Netflix Eureka 注册中心3. NacosNacos 致力于解决微服务中的统一配置、服务注册与发现等问题。它提供了一组简单易用的特性集，帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理；点击跳转：微服务架构 | 3.2 Alibaba Nacos 注册中心点击跳转：微服务架构 | *3.5 Nacos 服务注册与发现的源码分析4. ZookeeperZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等；点击跳转：微服务架构 | 3.3 Apache Zookeeper 注册中心5. ConsulConsul 是一套开源的分布式服务发现和配置管理系统，由 HashiCorp 公司用 Go 语言开发。它提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格，总之 Consul 提供了一种完整的服务网格解决方案；点击跳转：微服务架构 | 3.4 HashiCorp Consul 注册中心

前言参考资料：《Spring Microservices in Action》《Spring Cloud Alibaba 微服务原理与实战》《B站 尚硅谷 SpringCloud 框架开发教程 周阳》为方便理解与表达，这里把 Nacos 控制台和 Nacos 注册中心称为 Nacos 服务器（就是 web 界面那个），我们编写的业务服务称为 Nacso 客户端；Nacos 客户端将自己注册进 Nacos 服务器。《1. 服务如何注册进 Nacos 注册中心》主要从 Nacos 客户端角度解释如何发送信息给 Nacos 服务器；《2. Nacos 服务器注册服务》主要从 Nacos 服务器角度解释注册原理；《3. 客户端查询所有服务实例》将从服务消费者和提供者的角度，解释服务消费者如何获取提供者的所有实例。服务消费者和提供者都是 Nacos 的客户端；《4. 客户端监听 Nacos 服务器以动态获取服务实例》从消费者客户端角度出发监听 Nacos 服务器，以动态获知提供者的变化；1. 客户端注册进 Nacos 注册中心（客户端视角）1.1 Spring Cloud 提供的规范标准服务要注册进 Spring Cloud 集成的 Nacos，首先要满足 Spring Cloud 提供的规范标准；在 spring-cloud-common 包中有一个类 org.springframework.cloud.client.serviceregistry.ServiceRegistry，它是Spring Cloud 提供的服务注册的标准。集成到 Spring Cloud 中实现服务注册的组件，都会实现该接口；public interface ServiceRegistry<R extends Registration>{ void register(R registration); void deregister(R registration); void close(); void setStatus(R registration,String status); <T> T getstatus(R registration); }1.2 Nacos 的自动配置类在 spring-cloud-commons 包的 META-INF/spring.factories 中包含自动装配的配置信息。即约定 Spring Cloud 启动时，会将那些类自动注入到容器中：其中 AutoServiceRegistrationAutoConfiguration（服务注册自动配置类） 是服务注册相关配置类，源码如下：@Configuration @Import({AutoServiceRegistrationConfiguration.class}) @ConditionalOnProperty( value = {"spring.cloud.service-registry.auto-registration.enabled"}, matchIfMissing = true ) public class AutoServiceRegistrationAutoConfiguration { //自动注册类 @Autowired(required = false) private AutoServiceRegistration autoServiceRegistration; //自动注册类的配置文件 @Autowired private AutoServiceRegistrationProperties properties; public AutoServiceRegistrationAutoConfiguration() { } //初始化函数 @PostConstruct protected void init() { if (this.autoServiceRegistration == null && this.properties.isFailFast()) { throw new IllegalStateException("Auto Service Registration has been requested, but there is no AutoServiceRegistration bean"); } } }其中关键之处在于注入了一个 AutoServiceRegistration（服务注册器） 自动注册接口，该接口在 Spring Cloud 中有一个抽象实现类 AbstractAutoServiceRegistration（服务注册器抽象类）；我们要用什么注册中心，该注册中心就要继承 AbstractAutoServiceRegistration（服务注册器抽象类） 抽象类；对于 Nacos 来说，使用 NacosAutoServiceRegistration（Nacos 服务注册器） 类继承 AbstractAutoServiceRegistration（服务注册器抽象类） 抽象类；1.3 监听服务初始化事件 AbstractAutoServiceRegistration.bind()在上述中需要关注 ApplicationListener（事件监听器） 接口，它是一种事件监听机制，接口声明如下：@FunctionalInterface public interface ApplicationListener<E extends ApplicationEvent> extends EventListener { void onApplicationEvent(E var1); }AbstractAutoServiceRegistration（服务注册器抽象类） 使用 AbstractAutoServiceRegistration.bind() 方法实现了该接口，用来监听 WebServerInitializedEvent（服务初始化事件）；@Override @SuppressWarnings("deprecation") //【断点步入】 public void onApplicationEvent(WebServerInitializedEvent event) { bind(event); }我们给 AbstractAutoServiceRegistration.bind() 方法打上断点，启动服务提供者，可以发现：Nacos 服务器上没有服务注册实例；服务初始化已经完成；【结论】说明服务注册到 Nacos 的流程是先进行服务初始化，然后通过事件监听机制监听初始化事件。当初始化完成时，调用 AbstractAutoServiceRegistration.bind() 方法将服务注册进 Nacos 注册中心；1.4 注册服务实例的逻辑 NacosServiceRegistry.register()这里能说明什么时候服务会将自己的信息发给 Nacos 服务器；我们追进 AbstractAutoServiceRegistration.bind() 方法，发现在 AbstractAutoServiceRegistration（服务注册器抽象类） 里调用 NacosServiceRegistry.register() 方法后， Nacos 服务器上出现服务实例；我们追进 NacosServiceRegistry.register() 方法，方法的逻辑如下：@Override public void register(Registration registration) { //判断是否有服务 ID if (StringUtils.isEmpty(registration.getServiceId())) { log.warn("No service to register for nacos client..."); return; } String serviceId = registration.getServiceId(); //服务 ID（service-provider） Instance instance = getNacosInstanceFromRegistration(registration); //服务实例（里面有 ip、port 等信息） try { //【断点步入】注册的方法 namingService.registerInstance(serviceId, instance); log.info("nacos registry, {} {}:{} register finished", serviceId, instance.getIp(), instance.getPort()); } catch (Exception e) { log.error("nacos registry, {} register failed...{},", serviceId, registration.toString(), e); } }我们点进去 namingService.registerInstance() 方法（实现逻辑在 NacosNamingService.registerInstance()）得到注册的具体逻辑，如下：public void registerInstance(String serviceName, String groupName, Instance instance) throws NacosException { if (instance.isEphemeral()) { //用心跳 BeatInfo 封装服务实例信息 BeatInfo beatInfo = new BeatInfo(); beatInfo.setServiceName(NamingUtils.getGroupedName(serviceName, groupName)); beatInfo.setIp(instance.getIp()); beatInfo.setPort(instance.getPort()); beatInfo.setCluster(instance.getClusterName()); beatInfo.setWeight(instance.getWeight()); beatInfo.setMetadata(instance.getMetadata()); beatInfo.setScheduled(false); long instanceInterval = instance.getInstanceHeartBeatInterval(); beatInfo.setPeriod(instanceInterval == 0L ? DEFAULT_HEART_BEAT_INTERVAL : instanceInterval); //【断点步入 1.4.1】将 beatInfo 心跳信息放进 beatReactor 心跳发送器（发送心跳后，Nacos 服务器仍然没有服务实例） this.beatReactor.addBeatInfo(NamingUtils.getGroupedName(serviceName, groupName), beatInfo); } //【断点步入 1.4.2】使用 namingProxy 命名代理方式将服务实例信息以 POST 请求方式发送服务实例 this.serverProxy.registerService(NamingUtils.getGroupedName(serviceName, groupName), groupName, instance); }即注册服务实例的逻辑分两步：先通过 beatReactor.addBeatInfo 创建心跳信息实现健康检测；再以 POST 请求方式发送服务实例信息；1.4.1 心跳机制 BeatReactor.addBeatInfo()我们进入 BeatReactor.addBeatInfo() 方法一探心跳机制，源码如下：public void addBeatInfo(String serviceName, BeatInfo beatInfo) { LogUtils.NAMING_LOGGER.info("[BEAT] adding beat: {} to beat map.", beatInfo); this.dom2Beat.put(this.buildKey(serviceName, beatInfo.getIp(), beatInfo.getPort()), beatInfo); //【核心】定时向服务端发送一个心跳包 beatInfo this.executorService.schedule(new BeatReactor.BeatTask(beatInfo), 0L, TimeUnit.MILLISECONDS); //【核心】 MetricsMonitor.getDom2BeatSizeMonitor().set((double)this.dom2Beat.size()); }BeatReactor.addBeatInfo() 方法主要做了两件事：客户端调用 ScheduledExecutorService.schedule() 接口方法（靠 ScheduledThreadPoolExecutor（计划线程执行器） 实现）执行定时任务，在每个任务周期内定时向服务端发送一个心跳包 beatInfo；然后通过 MetricsMonitor.getDom2BeatSizeMonitor() 方法获取一个 心跳测量监视器（实际为 Gauge），不断检测服务端的回应，如果在设定时间内没有收到服务端的回应，则认为服务器出现了故障；Nacos 服务端会根据客户端的心跳包不断更新服务的状态；1.4.2 注册服务 NamingProxy.registerService()接着进入 NamingProxy.registerService() 方法，源码如下：public void registerService(String serviceName, String groupName, Instance instance) throws NacosException { LogUtils.NAMING_LOGGER.info("[REGISTER-SERVICE] {} registering service {} with instance: {}", new Object[]{this.namespaceId, serviceName, instance}); Map<String, String> params = new HashMap(9); params.put("namespaceId", this.namespaceId); params.put("serviceName", serviceName); params.put("groupName", groupName); params.put("clusterName", instance.getClusterName()); params.put("ip", instance.getIp()); params.put("port", String.valueOf(instance.getPort())); params.put("weight", String.valueOf(instance.getWeight())); params.put("enable", String.valueOf(instance.isEnabled())); params.put("healthy", String.valueOf(instance.isHealthy())); params.put("ephemeral", String.valueOf(instance.isEphemeral())); params.put("metadata", JSON.toJSONString(instance.getMetadata())); //【断点步入】这步执行完后，Nacos 服务器才出现服务实例信息 this.reqAPI(UtilAndComs.NACOS_URL_INSTANCE, params, (String)"POST"); }该方法先对服务实例做了封装，然后通过 NamingProxy.reqAPI() 方法拼凑注册服务的 API。 NamingProxy.reqAPI() 方法源码如下： public String reqAPI(String api, Map<String, String> params, List<String> servers, String method) { params.put("namespaceId", this.getNamespaceId()); if (CollectionUtils.isEmpty(servers) && StringUtils.isEmpty(this.nacosDomain)) { throw new IllegalArgumentException("no server available"); } else { Exception exception = new Exception(); if (servers != null && !servers.isEmpty()) { Random random = new Random(System.currentTimeMillis()); int index = random.nextInt(servers.size()); for(int i = 0; i < servers.size(); ++i) { String server = (String)servers.get(index); try { return this.callServer(api, params, server, method); } catch (NacosException var11) { exception = var11; LogUtils.NAMING_LOGGER.error("request {} failed.", server, var11); } catch (Exception var12) { exception = var12; LogUtils.NAMING_LOGGER.error("request {} failed.", server, var12); } index = (index + 1) % servers.size(); } throw new IllegalStateException("failed to req API:" + api + " after all servers(" + servers + ") tried: " + ((Exception)exception).getMessage()); } else { int i = 0; while(i < 3) { try { return this.callServer(api, params, this.nacosDomain); } catch (Exception var13) { exception = var13; LogUtils.NAMING_LOGGER.error("[NA] req api:" + api + " failed, server(" + this.nacosDomain, var13); ++i; } } throw new IllegalStateException("failed to req API:/api/" + api + " after all servers(" + servers + ") tried: " + ((Exception)exception).getMessage()); } } }1.5 以 Open API 方式发送注册请求最终将以 Open API 方式发送如下请求给 Nacos 服务器：POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?servicelame=nacos.naming.serviceName&ip=10.200.9.143&port=18082'1.6 小结Nacos 在先加载配置文件初始化服务，使用 ApplicationListener（事件监听器） 监听机制监听该服务初始化事件，当服务初始化完成后，进入 NacosServiceRegistry.register() 注册逻辑；注册原理分两步：先使用 NacosNamingService（Nacos 命名服务） 发送心跳；再使用 NamingProxy（命名代理），以 POST 请求方式发送服务实例给 Nacos 服务器；即 Nacos Service 必须要确保注册的服务实例是健康的（心跳检测），才能进行服务注册；2. Nacos 服务器注册服务（服务器视角）Nacos 服务器的源码下载、启动详情请见《微服务架构 | 3.2 Alibaba Nacos 注册中心》；上述提到客户端注册服务器的最后一步是向服务器发送如下 Open API 请求：POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?servicelame=nacos.naming.serviceName&ip=10.200.9.143&port=18082'那么服务器的源码分析将从这个请求开始；2.1 服务器接收请求 InstanceController.register()服务器在 nacos-naming 模块下 InstanceController（服务实例控制器） 里定义了一个 register 方法用来处理客户端的注册，源码如下：@RestController @RequestMapping(UtilsAndCommons.NACOS_NAMING_CONTEXT + "/instance") public class InstanceController { //省略其他代码 @CanDistro @PostMapping @Secured(parser = NamingResourceParser.class, action = ActionTypes.WRITE) public String register(HttpServletRequest request) throws Exception { //从请求体里解析出 namespaceId 命名空间（本例中是 public） final String namespaceId = WebUtils.optional(request, CommonParams.NAMESPACE_ID, Constants.DEFAULT_NAMESPACE_ID); //解析 serviceName 服务名（本例中是 DEFAULT_GROUP@@service-provider，实际就是service-provider） final String serviceName = WebUtils.required(request, CommonParams.SERVICE_NAME); NamingUtils.checkServiceNameFormat(serviceName); final Instance instance = parseInstance(request); //【断点步入】在服务器控制台注册服务实例的方法 serviceManager.registerInstance(namespaceId, serviceName, instance); return "ok"; } //省略其他代码 }2.2 在服务器控制台注册服务实例 ServiceManager.registerInstance()ServiceManager.registerInstance() 方法的源码如下：public void registerInstance(String namespaceId, String serviceName, Instance instance) throws NacosException { //【断点步入 2.3】创建空服务 createEmptyService(namespaceId, serviceName, instance.isEphemeral()); Service service = getService(namespaceId, serviceName); if (service == null) { throw new NacosException(NacosException.INVALID_PARAM, "service not found, namespace: " + namespaceId + ", service: " + serviceName); } //添加服务实例 addInstance(namespaceId, serviceName, instance.isEphemeral(), instance); }这段代码主要做了三个逻辑的内容：createEmptyService()：创建空服务（用于在 Nacos 服务器控制台的“服务列表”中展示服务信息），实际上是初始化一个 serviceMap，它是一个 ConcurrentHashMap 集合；getService()：从 serviceMap 中根据 namespaceld 和 serviceName 得到一个服务对象；addInstance()：把当前注册的服务实例保存到 Service 中；2.3 创建空服务 ServiceManager.createEmptyService()我们一直追进去，发现最后调用的是 ServiceManager.createServiceIfAbsent() 方法，源码如下：public void createServiceIfAbsent(String namespaceId, String serviceName, boolean local, Cluster cluster) throws NacosException { //通过命名空间 ID 和服务名从缓存中获取 service 服务，第一次是没有的，进入 if 语句创建 service Service service = getService(namespaceId, serviceName); if (service == null) { Loggers.SRV_LOG.info("creating empty service {}:{}", namespaceId, serviceName); service = new Service(); service.setName(serviceName); service.setNamespaceId(namespaceId); service.setGroupName(NamingUtils.getGroupName(serviceName)); // now validate the service. if failed, exception will be thrown service.setLastModifiedMillis(System.currentTimeMillis()); service.recalculateChecksum(); if (cluster != null) { cluster.setService(service); service.getClusterMap().put(cluster.getName(), cluster); } //判断服务是否有效，不生效将抛出异常 service.validate(); //【断点步入】添加与初始化服务 putServiceAndInit(service); if (!local) { addOrReplaceService(service); } } }第一次注册服务时缓存中肯定是没有的，我们进入到 if 语句里的 ServiceManager.putServiceAndInit() 方法；private void putServiceAndInit(Service service) throws NacosException { //【断点步入 2.3.1 】将服务添加到缓存 putService(service); service = getService(service.getNamespaceId(), service.getName()); //【断点步入 2.3.2 】建立心跳机制 service.init(); //【断点步入 2.3.3 】实现数据一致性的监听，将服务数据进行同步 consistencyService.listen(KeyBuilder.buildInstanceListKey(service.getNamespaceId(), service.getName(), true), service); consistencyService.listen(KeyBuilder.buildInstanceListKey(service.getNamespaceId(), service.getName(), false), service); Loggers.SRV_LOG.info("[NEW-SERVICE] {}", service.toJson()); }2.3.1 将服务添加到缓存 Service.putService()public void putService(Service service) { if (!serviceMap.containsKey(service.getNamespaceId())) { synchronized (putServiceLock) { if (!serviceMap.containsKey(service.getNamespaceId())) { serviceMap.put(service.getNamespaceId(), new ConcurrentSkipListMap<>()); } } } //将 Service 保存到 serviceMap 中 serviceMap.get(service.getNamespaceId()).putIfAbsent(service.getName(), service); }2.3.2 建立心跳机制 Service.init()public void init() { //【断点步入】定时检查心跳 HealthCheckReactor.scheduleCheck(clientBeatCheckTask); for (Map.Entry<String, Cluster> entry : clusterMap.entrySet()) { entry.getValue().setService(this); entry.getValue().init(); } }进入 HealthCheckReactor.scheduleCheck() 方法；public static void scheduleCheck(ClientBeatCheckTask task) { futureMap.computeIfAbsent(task.taskKey(), k -> GlobalExecutor.scheduleNamingHealth(task, 5000, 5000, TimeUnit.MILLISECONDS)); }其主要是通过创建定时任务不断检测当前服务下所有实例最后发送心跳包的时间。如果超时，则设置healthy为false表示服务不健康，并且发送服务变更事件；心跳检测机制可以用下图概述：2.3.3 实现数据一致性的监听 DelegateConsistencyServiceImpl.listen()@Override public void listen(String key, RecordListener listener) throws NacosException { // 这个键 key 会被两个服务监听 if (KeyBuilder.SERVICE_META_KEY_PREFIX.equals(key)) { //持久一致性服务 persistentConsistencyService.listen(key, listener); //短暂一致性服务 ephemeralConsistencyService.listen(key, listener); return; } mapConsistencyService(key).listen(key, listener); }2.4 小结Nacos 客户端通过 Open API 的形式发送服务注册请求，服务端收到请求后，做以下三件事：构建一个 Service 对象保存到 ConcurrentHashMap 集合中；使用定时任务对当前服务下的所有实例建立心跳检测机制；基于数据一致性协议将服务数据进行同步；至此，基于 Nacos 客户端和服务端的服务注册原理解析可以告一段落了，下面是一些补充内容；3. 客户端查询所有服务实例在进行 RPC 调用时，根据对服务的需求不同可以将 Nacos 客户端分为两种角色，分别是服务消费者和服务提供者；服务消费者需要使用提供者的服务，就先要向 Nacos 服务器获取所有已注册的服务提供者实例，第 3 点将讨论客户端（消费者）如何获取这些实例（提供者）；3.1 消费者客户端向 Nacos 发出请求与客户端向 Nacos 服务器注册服务一样，消费者客户端想要查询提供者的所有实例，也要向 Nacos 服务器发送请求；向 Nacos 服务器发送请求也是由两种形式，Open API 和 SDK。其中 SDK 最终也是以 Open API 方式发送的：Open API：GET 127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=service-providerSDK：List<Instance> selectInstances(String serviceName, boolean healthy)throws NacosException;我们使用 postman 发送 GET 127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=service-provider 请求，来模拟消费者客户端获取提供者实例；这里主要多发送几次请求，因为 Nacos 服务器可能缓存了所有提供者实例信息，可能直接从缓存中拿而不是处理请求；3.2 Nacos 服务器处理请求 InstanceController.list()Nacos 服务器处理获取所有服务实例的控制器还是 nacos-naming 模块下的 InstanceController（服务实例控制器）；InstanceController（服务实例控制器） 提供了一个 InstanceController.list() 接口处理该请求：可以看到我们的断点也被捕获；源码如下：@GetMapping("/list") @Secured(parser = NamingResourceParser.class, action = ActionTypes.READ) public ObjectNode list(HttpServletRequest request) throws Exception { //解析命名空间 ID String namespaceId = WebUtils.optional(request, CommonParams.NAMESPACE_ID, Constants.DEFAULT_NAMESPACE_ID); //解析服务名 String serviceName = WebUtils.required(request, CommonParams.SERVICE_NAME); NamingUtils.checkServiceNameFormat(serviceName); //解析获取一堆信息 String agent = WebUtils.getUserAgent(request); String clusters = WebUtils.optional(request, "clusters", StringUtils.EMPTY); String clientIP = WebUtils.optional(request, "clientIP", StringUtils.EMPTY); int udpPort = Integer.parseInt(WebUtils.optional(request, "udpPort", "0")); String env = WebUtils.optional(request, "env", StringUtils.EMPTY); boolean isCheck = Boolean.parseBoolean(WebUtils.optional(request, "isCheck", "false")); String app = WebUtils.optional(request, "app", StringUtils.EMPTY); String tenant = WebUtils.optional(request, "tid", StringUtils.EMPTY); boolean healthyOnly = Boolean.parseBoolean(WebUtils.optional(request, "healthyOnly", "false")); //【断点步入 3.2】获取所有服务的所有信息 return doSrvIpxt(namespaceId, serviceName, agent, clusters, clientIP, udpPort, env, isCheck, app, tenant, healthyOnly); }3.2 获取所有服务的所有信息 InstanceController.doSrvIpxt()InstanceController.doSrvIpxt() 方法很长，笔者删去一些非重点源码方便理解：public ObjectNode doSrvIpxt(String namespaceId, String serviceName, String agent, String clusters, String clientIP,int udpPort, String env, boolean isCheck, String app, String tid, boolean healthyOnly) throws Exception { //省略一些非核心代码 ClientInfo clientInfo = new ClientInfo(agent); ObjectNode result = JacksonUtils.createEmptyJsonNode(); //根据 namespaceld、serviceName 获得 Service 实例 Service service = serviceManager.getService(namespaceId, serviceName); List<Instance> srvedIPs; //获取指定服务下的所有实例，从Service实例中基于srvIPs得到所有服务提供者的实例信息 srvedIPs = service.srvIPs(Arrays.asList(StringUtils.split(clusters, ","))); //使用选择器过滤一些 ip if (service.getSelector() != null && StringUtils.isNotBlank(clientIP)) { srvedIPs = service.getSelector().select(clientIP, srvedIPs); } Map<Boolean, List<Instance>> ipMap = new HashMap<>(2); ipMap.put(Boolean.TRUE, new ArrayList<>()); ipMap.put(Boolean.FALSE, new ArrayList<>()); //过滤不健康实例 for (Instance ip : srvedIPs) { ipMap.get(ip.isHealthy()).add(ip); } //遍历完成 JSON 字符串的封装 ArrayNode hosts = JacksonUtils.createEmptyArrayNode(); for (Map.Entry<Boolean, List<Instance>> entry : ipMap.entrySet()) { List<Instance> ips = entry.getValue(); if (healthyOnly && !entry.getKey()) { continue; } for (Instance instance : ips) { //删除不可用的实例 if (!instance.isEnabled()) { continue; } ObjectNode ipObj = JacksonUtils.createEmptyJsonNode(); ipObj.put("ip", instance.getIp()); ipObj.put("port", instance.getPort()); ipObj.put("valid", entry.getKey()); ipObj.put("healthy", entry.getKey()); ipObj.put("marked", instance.isMarked()); ipObj.put("instanceId", instance.getInstanceId()); ipObj.set("metadata", JacksonUtils.transferToJsonNode(instance.getMetadata())); ipObj.put("enabled", instance.isEnabled()); ipObj.put("weight", instance.getWeight()); ipObj.put("clusterName", instance.getClusterName()); if (clientInfo.type == ClientInfo.ClientType.JAVA && clientInfo.version.compareTo(VersionUtil.parseVersion("1.0.0")) >= 0) { ipObj.put("serviceName", instance.getServiceName()); } else { ipObj.put("serviceName", NamingUtils.getServiceName(instance.getServiceName())); } ipObj.put("ephemeral", instance.isEphemeral()); hosts.add(ipObj); } } result.put("name", serviceName); result.put("cacheMillis", cacheMillis); result.put("lastRefTime", System.currentTimeMillis()); result.put("checksum", service.getChecksum()); result.put("useSpecifiedURL", false); result.put("clusters", clusters); result.put("env", env); result.replace("metadata", JacksonUtils.transferToJsonNode(service.getMetadata())); return result; }该方法的主要逻辑主要有三步：首先获取所有服务实例；过滤一些服务实例；遍历完成 JSON 字符串的封装并返回；4. 客户端监听 Nacos 服务器以动态获取服务实例消费者客户端角度出发监听 Nacos 服务器，以动态获知提供者的变化；4.1 客户端发送请求客户端服务有两种调用方式：void subscribe(String serviceName, EventListener listener) throws NacosException；public List<Instance> selectInstances(String serviceName, List<String> clusters, boolean healthy, boolean subscribe)，其中 subscribe 置为 true；4.2 服务动态感知的原理Nacos 客户端有一个 HostReactor 类，它的功能是实现服务的动态更新；客户端发起事件订阅后，在 HostReactor 中有一个 UpdateTask 线程，每 10s 发送一次 Pull 请求，获得服务端最新的地址列表；对于服务端，它和服务提供者的实例之间维持了心跳检测，一旦服务提供者出现异常，则会发送一个 Push 消息给 Nacos 客户端，也就是服务消费者；服务消费者收到请求之后，使用 HostReactor 中提供的 processServiceJSON 解析消息，并更新本地服务地址列表；原理可以用下图总结：4.3 Nacos 服务器处理请求服务器与本篇第 3 点相同，其中服务器的逻辑在《3.2 Nacos 服务器处理请求》；5. 补充内容5.1 Dubbo 的自动装配Spring Cloud Alibaba Dubbo 集成 Nacos 时，服务的注册是依托 Dubbo 中的自动装配机制完成的；spring-cloud-alibaba-dubbo 下的 META-INF/spring.factories 文件中自动装配了一个和服务注册相关的配置类 DubboServiceRegistrationNonWebApplicationAutoConfiguration（Dubbo 注册自动配置类）；@Configuration @ConditionalOnNotWebApplication @ConditionalOnProperty(value = "spring.cloud.service-registry.auto-registration.enabled", matchIfMissing = true) @AutoConfigureAfter(DubboServiceRegistrationAutoConfiguration.class) @Aspect public class DubboServiceRegistrationNonWebApplicationAutoConfiguration { @Autowired private ServiceRegistry serviceRegistry; //实现类为 NacosServiceRegistry ... //监听 ApplicationStartedEvent 事件，该事件在刷新上下文之后，调用 application 命令前触发； @EventListener(ApplicationStartedEvent.class) public void onApplicationStarted() { setServerPort(); //最终调用 NacosServiceRegistry.registry 方法实现服务注册 register(); } private void register() { if (registered) { return; } //这里即 NacosServiceRegistry.registry() serviceRegistry.register(registration); registered = true; } ... }NacosServiceRegistry.registry() 的原理详情请见本篇《1.4 注册服务实例的逻辑 NacosServiceRegistry.register()》；由此可以得出结论：Dubbo 集成 Nacos 时，服务的注册是依赖 Dubbo 的自动装配机制；而 Dubbo 的自动装配机制是依靠 NacosServiceRegistry.register() 实现的；6. 源码结构图总结源码结构图大致与本篇目录一致；6.1 客户端视角下的服务注册结构图AbstractAutoServiceRegistration.bind()：监听服务初始化事件；NacosServiceRegistry.register()：注册服务实例；NacosNamingService.registerInstance()：通过Nacos 命名服务注册服务实例；BeatReactor.addBeatInfo()：心跳机制；ScheduledThreadPoolExecutor.schedule()：执行定时任务，发送心跳包 beatInfo；MetricsMonitor.getDom2BeatSizeMonitor()：启动心跳测量监视器；NamingProxy.registerService()：以 Open API 方式发送注册请求；NamingProxy.reqAPI()：拼凑注册服务的 API；NamingProxy.callServer()：呼叫服务，发送请求；6.2 服务器视角下的服务注册结构图InstanceController.register()：服务器接收请求；ServiceManager.registerInstance()：在服务器控制台注册服务实例；ServiceManager.createEmptyService()：创建空服务；ServiceManager.createServiceIfAbsent()：如果空缺就创建服务；ServiceManager.putServiceAndInit()：初始化服务；Service.putService()：将服务添加到缓存；Service.init()：建立心跳机制；DelegateConsistencyServiceImpl.listen()：实现数据一致性的监听；ServiceManager.addInstance()：添加服务实例；KeyBuilder.buildInstanceListKey()：创建服务是一致性键；DelegateConsistencyServiceImpl.put()：将键和服务实例放 ConsistencyService 进行一致性维护；6.3 客户端查询所有服务实例结构图InstanceController.list()：服务器接收请求；InstanceController.doSrvIpxt()：获取所有服务的所有信息；ServiceManager.getService()：根据 namespaceld、serviceName 获得 service 实例；Service.srvIPs()：获取指定 service 服务下的所有实例；JacksonUtils.createEmptyArrayNode()：遍历完成 JSON 字符串的封装；

今天 Java 面试粉丝群里，一个一年开发经验的小伙伴只用了三天时间，找了一个 13 薪 1.5 万的工作，真是替他感到开心。高兴之余，让我们来看，今天的内容。本文是 Java 最常见的 200+ 面试题 的第三个补充模块。第一个补充模块：面试题补充① ThreadLocal 模块第二个补充模块：面试题补充② Netty 模块1.Dubbo 是什么？Dubbo 是一款高性能、轻量级的开源 RPC 框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。2.Dubbo 的使用场景有哪些？透明化的远程方法调用：就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。软负载均衡及容错机制：可在内网替代 F5 等硬件负载均衡器，降低成本，减少单点。服务自动注册与发现：不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。3.Dubbo 核心功能有哪些？Remoting：网络通信框架，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。4.Dubbo 核心组件有哪些？Provider：暴露服务的服务提供方Consumer：调用远程服务消费方Registry：服务注册与发现注册中心Monitor：监控中心和访问调用统计Container：服务运行容器5.Dubbo 服务器注册于发现的流程？Provider（提供者）绑定指定端口并启动服务。指供者连接注册中心，并发本机 IP、端口、应用信息和提供服务信息发送至注册中心存储。Consumer（消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心。注册中心根据消费者所求服务信息匹配对应的提供者列表发送至 Consumer 应用缓存。Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。Provider 状态变更会实时通知注册中心、在由注册中心实时推送至 Consumer。6.Dubbo 支持哪些协议，它们的优缺点有哪些？Dubbo： 单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步 Hessian 序列化。RMI： 采用 JDK 标准的 RMI 协议实现，传输参数和返回参数对象需要实现 Serializable 接口，使用 Java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。 多个短连接 TCP 协议传输，同步传输，适用常规的远程服务调用和 RMI 互操作。在依赖低版本的 Common-Collections 包，Java 序列化存在安全漏洞。WebService：基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互操作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用。HTTP： 基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器 JS 调用。Hessian：集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与 Hession 服务互操作。多个短连接，同步 HTTP 传输，Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件。Memcache：基于 Memcache实现的 RPC 协议。Redis：基于 Redis 实现的RPC协议。7.Dubbo 推荐什么协议？推荐使用 Dubbo 协议。8.Dubbo 有哪些注册中心？Multicast 注册中心：Multicast 注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现,基于网络中组播传输实现。Zookeeper 注册中心：基于分布式协调系统 Zookeeper 实现，采用 Zookeeper 的 watch 机制实现数据变更。Redis 注册中心：基于 Redis 实现，采用 key/map 存储，住 key 存储服务名和类型，map 中 key 存储服务 url，value 服务过期时间。基于 Redis 的发布/订阅模式通知数据变更。Simple 注册中心。9.Dubbo 的注册中心集群挂掉，发布者和订阅者之间还能通信么？可以通讯。启动 Dubbo 时，消费者会从 Zookeeper 拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。10.Dubbo 使用的是什么通信框架?默认使用 Netty 作为通讯框架。11.Dubbo集群提供了哪些负载均衡策略？Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀。RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题。LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求。ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动。默认为 Random 随机调用。12.Dubbo的集群容错方案有哪些？Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。Failsafe Cluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。默认的容错方案是 Failover Cluster。13.Dubbo 支持哪些序列化方式？默认使用 Hessian 序列化，还有 Duddo、FastJson、Java 自带序列化。14.Dubbo 超时设置有哪些方式？Dubbo 超时设置有两种方式：服务提供者端设置超时时间，在Dubbo的用户文档中，推荐如果能在服务端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。15.服务调用超时会怎么样？dubbo 在调用服务不成功时，默认是会重试两次。16.Dubbo 在安全方面有哪些措施？Dubbo 通过 Token 令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo 还提供服务黑白名单，来控制服务所允许的调用方。17.Dubbo 类似的分布式框架还有哪些？比较著名的就是 Spring Cloud。18.Dubbo 和 Spring Cloud 有什么关系？Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是打造一个生态。19.Dubbo 和 Spring Cloud 有什么哪些区别？Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。Spring Cloud 是基于 Http 协议 Rest 接口调用远程过程的通信，相对来说 Http 请求会有更大的报文，占的带宽也会更多。但是 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。最后关于更多 Dubbo 的信息，访问官网：http://dubbo.incubator.apache.org/zh-cn/查看所有面试题：Java 最常见的 200+ 面试题参考文章http://youzhixueyuan.com/dubbo-interview-question-answers.html

1.Netty 是什么？Netty 是一款基于 NIO（Nonblocking I/O，非阻塞IO）开发的网络通信框架，对比于 BIO（Blocking I/O，阻塞IO），他的并发性能得到了很大提高。难能可贵的是，在保证快速和易用性的同时，并没有丧失可维护性和性能等优势。2.Netty 的特点是什么？高并发：Netty 是一款基于 NIO（Nonblocking IO，非阻塞IO）开发的网络通信框架，对比于 BIO（Blocking I/O，阻塞IO），他的并发性能得到了很大提高。传输快：Netty 的传输依赖于零拷贝特性，尽量减少不必要的内存拷贝，实现了更高效率的传输。封装好：Netty 封装了 NIO 操作的很多细节，提供了易于使用调用接口。3.什么是 Netty 的零拷贝？Netty 的零拷贝主要包含三个方面：Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行 Socket 读写，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。Netty 提供了组合 Buffer 对象，可以聚合多个 ByteBuffer 对象，用户可以像操作一个 Buffer 那样方便的对组合 Buffer 进行操作，避免了传统通过内存拷贝的方式将几个小 Buffer 合并成一个大的 Buffer。Netty 的文件传输采用了 transferTo 方法，它可以直接将文件缓冲区的数据发送到目标 Channel，避免了传统通过循环 write 方式导致的内存拷贝问题。4.Netty 的优势有哪些？使用简单：封装了 NIO 的很多细节，使用更简单。功能强大：预置了多种编解码功能，支持多种主流协议。定制能力强：可以通过 ChannelHandler 对通信框架进行灵活地扩展。性能高：通过与其他业界主流的 NIO 框架对比，Netty 的综合性能最优。稳定：Netty 修复了已经发现的所有 NIO 的 bug，让开发人员可以专注于业务本身。社区活跃：Netty 是活跃的开源项目，版本迭代周期短，bug 修复速度快。5.Netty 的应用场景有哪些？典型的应用有：阿里分布式服务框架 Dubbo，默认使用 Netty 作为基础通信组件，还有 RocketMQ 也是使用 Netty 作为通讯的基础。6.Netty 高性能表现在哪些方面？IO 线程模型：同步非阻塞，用最少的资源做更多的事。内存零拷贝：尽量减少不必要的内存拷贝，实现了更高效率的传输。内存池设计：申请的内存可以重用，主要指直接内存。内部实现是用一颗二叉查找树管理内存分配情况。串形化处理读写：避免使用锁带来的性能开销。高性能序列化协议：支持 protobuf 等高性能序列化协议。7.Netty 和 Tomcat 的区别？作用不同：Tomcat 是 Servlet 容器，可以视为 Web 服务器，而 Netty 是异步事件驱动的网络应用程序框架和工具用于简化网络编程，例如TCP和UDP套接字服务器。协议不同：Tomcat 是基于 http 协议的 Web 服务器，而 Netty 能通过编程自定义各种协议，因为 Netty 本身自己能编码/解码字节流，所有 Netty 可以实现，HTTP 服务器、FTP 服务器、UDP 服务器、RPC 服务器、WebSocket 服务器、Redis 的 Proxy 服务器、MySQL 的 Proxy 服务器等等。8.Netty 中有那种重要组件？Channel：Netty 网络操作抽象类，它除了包括基本的 I/O 操作，如 bind、connect、read、write 等。EventLoop：主要是配合 Channel 处理 I/O 操作，用来处理连接的生命周期中所发生的事情。ChannelFuture：Netty 框架中所有的 I/O 操作都为异步的，因此我们需要 ChannelFuture 的 addListener()注册一个 ChannelFutureListener 监听事件，当操作执行成功或者失败时，监听就会自动触发返回结果。ChannelHandler：充当了所有处理入站和出站数据的逻辑容器。ChannelHandler 主要用来处理各种事件，这里的事件很广泛，比如可以是连接、数据接收、异常、数据转换等。ChannelPipeline：为 ChannelHandler 链提供了容器，当 channel 创建时，就会被自动分配到它专属的 ChannelPipeline，这个关联是永久性的。9.Netty 发送消息有几种方式？Netty 有两种发送消息的方式：直接写入 Channel 中，消息从 ChannelPipeline 当中尾部开始移动；写入和 ChannelHandler 绑定的 ChannelHandlerContext 中，消息从 ChannelPipeline 中的下一个 ChannelHandler 中移动。10.默认情况 Netty 起多少线程？何时启动？Netty 默认是 CPU 处理器数的两倍，bind 完之后启动。11.Netty 支持哪些心跳类型设置？readerIdleTime：为读超时时间（即测试端一定时间内未接受到被测试端消息）。writerIdleTime：为写超时时间（即测试端一定时间内向被测试端发送消息）。allIdleTime：所有类型的超时时间。参考文档https://blog.csdn.net/chenssy/article/details/78703551https://blog.csdn.net/summerZBH123/article/details/79344226https://blog.csdn.net/thinking_fioa/article/details/80588138https://www.jianshu.com/p/a199ca28e80dhttps://blog.csdn.net/linuu/article/details/51385682

前言参考资料：《Spring Microservices in Action》《Spring Cloud Alibaba 微服务原理与实战》《B站 尚硅谷 SpringCloud 框架开发教程 周阳》《Zookeeper 教程》《Zookeeper 官网》ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等；1. Zookeeper 基础知识1.1 Zookeeper 是什么Zookeeper 是一个分布式协调工具，可以实现注册中心功能；是 Apache Hadoop 的一个子项目，用来解决分布式应用中经常遇到的一些数据管理问题。包括：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等；简单来说：zookeeper=文件系统+监听通知机制；ZooKeeper 的架构通过冗余服务实现高可用性；【注意】ZooKeeper 本身并不是注册中心，只是基于 ZooKeeper 本身的特性可以实现注册中心这个场景；1.2 Zookeeper 的数据结构系统概述：ZooKeeper 的数据模型和分布式文件系统类似，是一种层次化的属性结构；和文件系统不同的是，ZooKeeper 的数据是结构化存储的，并没有在物理上体现出文件和目录；ZooKeeper 上的每个节点的数据都是允许读和写，且必须要按照层级创建；Znode 节点：Zookeeper 中的所有存储的数据是由 Znode 组成，并以 key/value 形式存储数据；ZooKeeper 只是管理和协调有关的数据，所以 value 的数据大小不建议设置得非常大，较大的数据会带来更大的网络开销；Znode 维护一个 stat 状态信息，其中包含数据变化的时间和版本等；stat 状态信息：| 属性 | 说明 | |:--|:--| | cZxid | 创建节点时的事务 ID | | ctime | 创建节点时的时间 | | mZxid | 最后修改节点时的事务 ID | | mtime | 最后修改节点时的时间 | | pZxid | 表示该节点的子节点列表最后一次修改的事务 ID（包括增删子节点，不包括改子节点内容） | | cversion | 子节点版本号，子节点每次修改版本号加 1 | | dataversion | 数据版本号，数据每次修改该版本号加 1 | | aclversion | 权限版本号，权限每次修改该版本号加 1 | | ephemeralOwner | 创建该临时节点的会话的 sessionID（持久节点，该属性值为 0） | | dataLength | 该节点的数据长度 | | numChildren | 该节点拥有直接子节点的数量 |Znode 的节点类型：持久化节点：节点的数据会持久化到磁盘；临时节点：节点的生命周期和创建该节点的客户端的生命周期保持一致。客户端会话结束，则该临时节点删除；有序节点：在创建的节点后增加一个递增的序列，该序列在同一级父节点之下是唯一的；容器节点：容器节点下最后一个子节点被删除时，容器节点自动删除（3.5.3版本后）；TTL 节点：设置一个存活时间，如果在存活时间之内该节点没有任何修改并且没有子节点，则自动删除（3.5.3版本后）；一个示例图：1.3 Watcher 机制一种针对 Znode 的订阅/通知机制；当 Znode 节点状态发生变化时或者 ZooKeeper 客户端连接状态发生变化时，会触发事件通知；该机制在服务注册与发现中，用于服务调用者及时感知到服务提供者的变化；ZooKeeper 提供了三种 JavaAPI 机制进行对 Znode 进行注册监听：getData()：用于获取指定节点的 value 信息，并且可以注册监听，当监听的节点进行创建、修改、删除操作时，会触发相应的事件通知；getChildren()：用于获取指定节点的所有子节点，并且允许注册监听，当监听节点的子节点进行创建、修改、删除操作时，触发相应的事件通知；exists()：用于判断指定节点是否存在，同样可以注册针对指定节点的监听，监听的时间类型和 getData() 相同Watcher 事件的触发都是一次性的，客户端在发现节点修改后需要在事件回调中再次注册事件；1.4 常见应用场景分析分布式锁：排他性：避免在同一时刻多个进程同时访问某一个共享资源；基于节点的性质：临时节点、同级节点的唯一性；获得锁的过程：在获得排他锁时，所有客户端可以去 ZooKeeper 服务器上 /Exclusive_Locks 节点下创建一个临时节点 /lock。只有一个客户端能创建成功；释放锁的过程：有两种情况：获得锁的客户端因为异常断开了和服务端的连接，基于临时节点的特性，/lock 节点会被自动删除；获得锁的客户端执行完业务逻辑之后，主动删除了创建的 /lock 节点；Master 选举：当集群机器中有一个机器宕机后，其他机器会接替故障机器继续工作；基于节点的性质有两种实现方式：唯一性：类似分布式锁。在 ZooKeeper 服务器上创建一个临时节点 /master-election，只有成功创建的机器工作。其他机器针对该节点注册 Watcher 事件；临时有序节点：所有参与选举的客户端在 ZooKeeper 服务器的 /master 节点下创建一个临时有序节点，编号最小的节点表示 Master，后续的节点可以监听前一个节点的删除事件，用于触发重新选举。如下图所示：1.5 Zookeeper 的版本冲突问题Zookeeper 的依赖如下：<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId> </dependency>如果我们直接添加这个依赖可能会出现以下问题，出现以下日志信息是说明出现 Zookeeper 版本冲突问题：原因是：上述依赖自带 3.5.3beta 的版本，与本地的下载的 zookeeper 版本对应不上；可以通过修改 pom.xml 文件解决；修改后的示例请见本篇《2.1 引入 pom.xml 依赖》；1.6 Zookeeper 注册中心的实现原理本篇或《12.1 使用 Apache Dubbo 实现远程通信》里的《5. Dubbo 使用 Zookeeper 作为注册中心》构建了如下示例；当 Dubbo 服务启动时：在 Zookeeper 服务器上的 /dubbo/com.dlhjw.dubbo.service.impl.TestServiceImpl/providers 目录下创建当前服务的 URL；com.dlhjw.dubbo.service.impl.TestServiceImpl 表示发布服务的接口全路径名称；providers 表示服务提供者的类型；dubbo://ip:port 表示该服务发布的协议类型及访问地址；URL 是临时节点，其他皆为持久化节点；当 Dubbo 服务消费者启动时：对 /dubbo/com.dlhjw.dubbo.service.impl.TestServiceImpl/providers 目录下子节点注册 Watcher 监听；服务消费者会在 /dubbo/com.dlhjw.dubbo.service.impl.TestServiceImpl/consumers 目录下写入自己的 URL；服务消费者如果需要调用 TestServiceImpl 服务，它会先去 /dubbo/com.dlhjw.dubbo.service.impl.TestServiceImpl/providers 路径下获得所有该服务的提供方 URL 列表，然后通过负载均衡算法计算出一个地址进远程访问；1.7 下面示例的相关说明客户端（在这里体现不出来）调用服务消费者的 http://consumer/zk 接口，请求消费者的资源；接着服务消费者通过负载均衡算法调用 http://zkcloud-provider/provider/zk 接口，请求服务提供者的资源；2. 安装并运行 Zookeeper 服务器基于 Win10 下的 Zookeeper 服务器安装；2.1 下载 Zookeeper访问连接：https://zookeeper.apache.org/releases.html；下载解压后：2.2 修改配置到 apache-zookeeper-3.7.0-bin\apache-zookeeper-3.7.0-bin\conf 目录下，备份一份 zoo_sample.cfg 配置文件；tickTime：Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每隔 tickTime 时间就会发送一个心跳；dataDir：Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里；dataLogDir：Zookeeper 保存日志文件的目录；clientPort：客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求；注意：查看 bin 目录下的 zkEvn.cmd 里的 JAVA_HOME 名字对不对；2.3 运行 Zookeeper 服务器到 bin 目录下：双击 zkServer.cmd，会启动一个 java 进程，即服务端；双击 zkCli.cmd，会启动一个客户端 ；3. 使用 Zookeeper 管理服务提供者使用 Zookeeper 构建服务提供者大致与 Nacos 和 Consul 相同； Nacos 与 Consul 的构建方式详情请见《3.2 Alibaba Nacos 注册中心》与《3.4 HashiCorp Consul 注册中心》；3.1 引入 pom.xml 依赖<!-- SpringBoot整合zookeeper客户端 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId> <!--先排除自带的zookeeper--> <exclusions> <exclusion> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> </exclusion> </exclusions> </dependency> <!--添加zookeeper3.4.9版本，这里可根据自己本地的下载的 zookeeper 版本进行配置--> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.9</version> </dependency>Spring 管理的依赖自带 3.5.3beta 版本，与本地的下载的 zookeeper 版本对应不上，可以通过修改 pom 文件解决；3.2 修改 boostrap.yml 配置文件#8004表示注册到zookeeper服务器的支付服务提供者端口号 server: port: 8004 #服务别名----注册zookeeper到注册中心名称 spring: application: name: zkcloud-provider cloud: zookeeper: connect-string: 192.168.111.144:21813.3 在主启动类上添加注解@EnableDiscoveryClient：使用其他组件（Nacos、zookeeper、Consul）作为注册中心；3.4 编写业务类，并在 controller 层开放接口这里编写一个简单接口仅作为示例；@RestController public class providerController{ @Value("${server.port}") private String serverPort; @RequestMapping(value = "/provider/zk") public String providerzk(){ return "springcloud with zookeeper: "+serverPort+"\t"+ UUID.randomUUID().toString(); } }4. 使用 Zookeeper 管理服务消费者使用 Zookeeper 构建服务消费者大致与 Nacos 和 Consul 相同； Nacos 与 Consul 的构建方式详情请见《3.2 Alibaba Nacos 注册中心》与《3.4 HashiCorp Consul 注册中心》；4.1 引入 pom.xml 依赖同服务提供者端的依赖；<!-- SpringBoot整合zookeeper客户端 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId> <!--先排除自带的zookeeper--> <exclusions> <exclusion> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> </exclusion> </exclusions> </dependency> <!--添加zookeeper3.4.9版本--> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.9</version> </dependency>4.2 修改 boostrap.yml 配置文件server: port: 80 spring: application: name: zkcloud-consumer cloud: #注册到zookeeper地址 zookeeper: connect-string: 192.168.111.144:21814.3 主启动类上不需要添加额外注解4.4 编写业务类，调用提供者接口由于我们使用 Ribbon + RestTemplate 的负载均衡策略，因此需要在 IoC 容器中添加一个 RestTemplate JavaBean；详情请见《4.1 基于 Ribbon 的负载均衡详解》；该 Bean 可以在主启动类中添加；也可以在主启动类所在包或子包的 config 包中添加，如下：@Configuration public class ApplicationContextBean{ @Bean @LoadBalanced public RestTemplate getRestTemplate(){ return new RestTemplate(); } }我们在 controller 层开放接口给客户端，并在该接口里调用提供者的 API；@RestController public class ComsumerZKController{ public static final String INVOKE_URL = "http://zkcloud-provider"; @Autowired private RestTemplate restTemplate; @RequestMapping(value = "/consumer/zk") public String paymentInfo(){ String result = restTemplate.getForObject(INVOKE_URL+"/provider/zk", String.class); System.out.println("消费者调用提供者获取服务--->result:" + result); return result; } }5. Dubbo 使用 Zookeeper 作为注册中心详情请见：本系列另外一篇文章《12.1 使用 Apache Dubbo 实现远程通信》里的《5. Dubbo 使用 Zookeeper 作为注册中心》；

手把手教你分析解决MySQL死锁问题在生产环境中如果出现MySQL死锁问题该如何排查和解决呢，本文将模拟真实死锁场景进行排查，最后总结下实际开发中如何尽量避免死锁发生。一、准备好相关数据和环境当前自己的数据版本是8.0.22mysql> select @@version; +-----------+ | @@version | +-----------+ | 8.0.22 | +-----------+ 1 row in set (0.00 sec)数据库隔离级别(默认隔离级别)mysql> select @@transaction_isolation; +-------------------------+ | @@transaction_isolation | +-------------------------+ | REPEATABLE-READ | +-------------------------+ 1 row in set (0.00 sec)自动提交关闭mysql> select @@autocommit; +--------------+ | @@autocommit | +--------------+ | 1 | +--------------+ 1 row in set (0.00 sec) mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select @@autocommit; +--------------+ | @@autocommit | +--------------+ | 0 | +--------------+ 1 row in set (0.00 sec)表结构这个age为 非唯一索引，这点对下面整个案例非常重要。-- id是自增主键，age是非唯一索引，name普通字段 CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `age` int DEFAULT NULL COMMENT '年龄', `name` varchar(255) DEFAULT NULL COMMENT '姓名', PRIMARY KEY (`id`), KEY `idx_age` (`age`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户信息表';表中暂时先插入两条数据二、模拟出真实死锁案例开启两个终端模拟事务并发情况，执行顺序以及实验现象如下：1）事务A执行更新操作，更新成功mysql> update user set name = 'wangwu' where age= 20; Query OK, 1 row affected (0.00 sec)事务B执行更新操作，更新成功mysql> update user set name = 'zhaoliu' where age= 10; Query OK, 1 row affected (0.00 sec)3）事务A执行插入操作，陷入阻塞~mysql> insert into user values (null, 15, "tianqi");4）事务B执行插入操作，插入成功，同时事务A的插入由阻塞变为死锁error。insert into user values (null, 30, "wangba"); Query OK, 1 row affected (0.00 sec)事务A的插入操作变成报错。上面四步操作后，我们分别对事务A和事务B进行commit操作。mysql> commit; Query OK, 0 rows affected (0.00 sec)我们再来看数据库中表的数据。我们发现，事务B的所有操作最终都成功了，而事务A的操作因为报错都回滚了。所以事务A的操作都失败。那既然是死锁，为什么回滚事务A,而不是事务B,是随机的还是有机制在里面？我们可以理解死锁是数据库对事务的保护机制,一旦发生死锁,MySQL会选择相对小的事务(undo较少的)进行回滚。 三、查看分析死锁日志可以用 show engine innodb status，查看最近一次死锁日志哈，执行后，死锁日志如下(只展示部分日志)：LATEST DETECTED DEADLOCK ------------------------ 2021-12-24 06:02:52 0x7ff7074f8700 *** (1) TRANSACTION: TRANSACTION 2554368, ACTIVE 22 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 2 INSERT INTO user VALUES (NULL, 15, "tianqi") *** (1) HOLDS THE LOCK(S): RECORD LOCKS space id 309 page no 5 n bits 72 index idx_age of table `mall_goods`.`user` trx id 2554368 lock_mode X Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;; *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 309 page no 5 n bits 72 index idx_age of table `mall_goods`.`user` trx id 2554368 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 80000014; asc ;; 1: len 4; hex 80000002; asc ;; *** (2) TRANSACTION: TRANSACTION 2554369, ACTIVE 14 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 5 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 2 INSERT INTO user VALUES (NULL, 30, "wangba") *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 309 page no 5 n bits 72 index idx_age of table `mall_goods`.`user` trx id 2554369 lock_mode X locks gap before rec Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 80000014; asc ;; 1: len 4; hex 80000002; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 309 page no 5 n bits 72 index idx_age of table `mall_goods`.`user` trx id 2554369 lock_mode X insert intention waiting Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;; *** WE ROLL BACK TRANSACTION (1)1、事务A相关日志1）找到关键词TRANSACTION，事务25543682）查看事务1正在执行的sqlinsert into user values (null, 15, "tianqi")查看当前事务已占有的锁和等待其它事务释放的锁2、事务B相关日志1）找到关键词TRANSACTION，事务25543692）查看事务2正在执行的sqlinsert into user values (null, 30, "wangba")查看当前事务已占有的锁和等待其它事务释放的锁3、总结这里把一些关键的日志截图了下我们把这张图换一种方式画下1）从图中可以很明显的看出,事务1和事务2都在等对方的锁释放，所以导致了死锁问题。而且最终是事务1进行了回滚。2）这个日志提供比较重要的信息就是我们可以看出的是哪两条sql在互相一直等待其它事务的锁释放而产生了死锁，也知道是哪个索引导致产生的死锁，同时也知道最终哪个事务被回滚了。3）如果上面的信息还不能帮你定位解决问题，那可以问数据库DB要详细的binlog日志来分析这段时间这两个事务具体执行的所有sql。 四、总结分析案例中产生死锁的原因这个分析就需要对MySQL中的各种锁机制有所了解，还不清楚的话可以看我之前写的两篇文章，看完你就清楚我下面所写的了。一文详解MySQL的锁机制MySQL记录锁、间隙锁、临键锁小案例演示1、事务A的SQL产生了哪些锁1) 事务A的update语句产生哪些锁我们先来看update user set name = 'wangwu' where age= 20;记录锁因为是等值查询，所以这里会在满足age=20的所有数据请求一个记录锁。间隙锁因为这里是非唯一索引的等值查询,所以一样会产生间隙锁(如果是唯一索引的等值查询那就不会产生间隙锁，只会有记录锁),因为这里只有2条记录所以左边为(10,20),右边因为没有记录了，所以请求间隙锁的范围就是(20,+∞),加一起就是(10,20) +（20,+∞)。Next-Key锁Next-Key锁=记录锁+间隙锁，所以该Update语句就有了（10,+∞)的 Next-Key锁事务A的install语句产生哪些锁INSERT INTO user VALUES (NULL, 15, "tianqi");间隙锁因为age 15(在10和20之间)，所以需要请求加(10,20)的间隙锁插入意向锁（Insert Intention）插入意向锁是在插入一行记录操作之前设置的一种间隙锁，这个锁释放了一种插入方式的信号，即事务A需要插入意向锁(10,20),这个插入锁的作用就是提高插入效率的，在分析死锁的时候我们可以不用关心它，只关心上面间隙锁就好了。2、事务B的SQL产生了哪些锁事务B的update语句产生哪些锁我们先来看update user set name = 'zhaoliu' where age= 10记录锁因为是等值查询，所以这里会在满足age=10的所有数据请求一个记录锁。间隙锁因为左边没有记录,右边有一个age=20的记录，所以间隙锁的范围是(-∞,10),右边为(10,20),一起就是(-∞,10)+(10,20)。Next-Key锁Next-Key锁=记录锁+间隙锁，所以该Update语句就有了（-∞,20)的 Next-Key锁事务A的install语句产生哪些锁INSERT INTO user VALUES (NULL, 30, "wangba")间隙锁因为age 30(左边是20，右边没有值)，所以需要请求加(20,+∞)的间隙锁插入意向锁（Insert Intention）(20,+∞)锁都分析清楚了，接下来再来看下是什么地方导致死锁的呢？这样以来产生整个死锁的原因也就清楚了，不过这里再补充两点1）MySQL的间隙锁虽然有左开右闭的原则,但是其实这个并不完全正确,因为它有可能是左闭右开,也可能是左开右开，它会跟你插入主键值位置有关，具体的可以看我之前写的一篇文章里面有完整示例MySQL记录锁、间隙锁、临键锁小案例演示。所以这里间隙锁写的都是左开右开的范围，可能临界点有点模糊，但不影响分析这个案例的死锁问题。2）通过事务A和事务B的update语句，我们可以发现其实它们都持有间隙锁(10,20)的这段范围,说明间隙锁范围是可以相互兼容的，意思就是只要你的10不在我（10,+∞)的间隙锁范围内，那就可以产生部分重合的间隙锁，也就是这里的(10,20)。 五、实际开发中如何尽量避免死锁发生一般来讲在实际开发中，很少会发生死锁的情况，尤其是在业务并发量不是很大的情况下。在并发很大的情况下可能会存在偶尔产生死锁。不过呢，在自己实际开发中，有遇到过请求一个接口出现100%概率死锁的情况。当时的场景其实很简单。一段业务代码中，有去走Dubbo调其它接口服务,这就存在了两个事务,结果各自事务提交的时候，都需要等待对方的锁释放，就导致每次都发生死锁超时。这其实是一种代码不规范而导致死锁的发生。这里也总结下如何尽量避免死锁发生。1）不同的应用访问同一组表时，应尽量约定以相同的顺序访问各表。对一个表而言，应尽量以固定的顺序存取表中的行。这点真的很重要,它可以明显的减少死锁的发生。举例：好比有a,b两张表，如果事务1先a后b,事务2先b后a,那就可能存在相互等待产生死锁。那如果事务1和事务2都先a后b，那事务1先拿到a的锁，事务2再去拿a的锁，如果锁冲突那就会等待事务1释放锁，那自然事务2就不会拿到b的锁，那就不会堵塞事务1拿到b的锁，这样就避免死锁了。2）在主键等值更新的时候，尽量先查询看数据库中有没有满足条件的数据，如果不存在就不用更新，存在才更新。为什么要这么做呢，因为如果去更新一条数据库不存在的数据，一样会产生间隙锁。举例：如果表中只有id=1和id=5的数据，那么如果你更新id=3的sql，因为这条记录表中不存在，那就会产生一个(1,5)的间隙锁，但其实这个锁就是多余的，因为你去更新一个数据都不存在的数据没有任何意义。3）尽量使用主键更新数据,因为主键是唯一索引，在等值查询能查到数据的情况下只会产生行锁，不会产生间隙锁，这样产生死锁的概率就减少了。当然如果是范围查询，一样会产生间隙锁。4）避免长事务，小事务发送锁冲突的几率也小。这点应该很好理解。5）在允许幻读和不可重复度的情况下，尽量使用RC的隔离级别，避免gap lock造成的死锁，因为产生死锁经常都跟间隙锁有关，间隙锁的存在本身也是在RR隔离级别来解决幻读的一种措施。 感谢这篇文章给自己提供了很好的思路，这篇文章也基本上按照这个思路往下写的手把手教你分析MySQL死锁问题转载地址https://www.cnblogs.com/qdhxhz/p/15735876.html

领读：这篇文章比较简要，说了一下主流的选型，小公司可以快速搭建项目！一般来说，我建议大家先找开源项目，能在现成开源项目上再二次修改，这样无疑大量减少开发时间和提高效率！其实这里面主要给大家说的是技术选型。由于我中型互联网公司工作，针对用于手机 APP 或者 pc 的后台开发，基本可以支撑几万用户。本文会对可能用到的相关技术进行技术选型的说明，以及技术的架构介绍技术指标说一下一些技术指标的计算过程可以作为其他同学的参考QPS， 如果是 5 万日活，使用集中在每天的 4 小时，每个用户大概产生 100 的请求，那么平均下来，我们系统大概应该支撑的请求为：50000 * 100 / (4 * 60 * 60) = 350 qps/s业务数据 业务量，我们自己是新闻业务，可能会有其他的业务，比如游戏，商城等等，基本每天新增的业务数据都会在同一个量级， 每日 10000， 另外跟用户相关的信息也是比较大的一块，比如用户的订阅等行为，一共 5 万的用户，保存相关信息可能大概需要 100 条的数据。缓存大小 主要业务数据和用户相关的热点数据限时保存在缓存中， 大概需要 5 个 G 左右。日志大小 用户日志和请求日志。大概每天 3 个 G 左右这些数据需要运维人员的估算，技术架构我们基于阿里云来搭建，对图中的内容和技术选型进行一下说明：负载均衡可选方案：SLB, Nginx.SLB 要收钱，但是比较便宜，有保证，不会挂。但是可配置的很少，不能根据域名做 ip 映射Nginx, 没啥缺点，需要一定的知识。建议：SLB + Nginx, SLB 绑定域名作为统一的入口，然后每个服务器上再搭建 Nginx.大多数金融公司的选择CDN用于缓存静态文件等等。七牛和阿里的都还可以。七牛要做的久一点， 各种图片处理的接口要完善一些阿里的 CDN 要稍微好一点点， 但是没有不安全的访问方式，访问稍微没有那么灵活。图片处理功能弱一点。是解决前端延迟的好办法搜索公纵号：MarkerHub，关注回复[ vue ]获取前后端入门教程！分布式调用框架目前可选的有 ZK + dubbo. ZK + Motan, ZK + dubbox, edas。dubbo, 阿里的服务治理框架，已经不维护了，切换反应有点慢dubboX, 当当基于 dubbo 搞的，还在维护可以一用，推荐。Motan, 微博的服务治理矿建， 刚开源，需要学习一下， 推荐。Edas, 阿里云服务，要收钱，侵入型很强，不推荐MQ可选的有：ActiveMQ, rocketMQ， robbitMQ,Kafka 各有好处， 但是考虑到运维的难度，推荐 rocketMQ。Redis用来做缓存， 自建成本有点高，需要 Codis, 分片，集群，主从等等，很麻烦。建议直接用阿里的也可以用来处理分布式的数据共享 session 的工具、数据库主要基于读写分离和主从复制考虑，目前可以自建和选用阿里的 DRDS。DRDS 要花钱，成本较高，没有必要自建， 不用中间件，直接 1 写 2 只读， 然后配置读写分离的数据源，内网 SLB 进行读集群。解决之。搜索apache solr 搜索引擎。相比其他用起来还可以。建议 ELK， 可以自动同步数据库，除了搜索引擎的功能外，还可以做日志搜索，监控系统。代码管理工具Jenkins 与 Sonar 集成是代码管理工具重要体现。apache 中 sonar 代码管理。是我们优化方案找出代码不规格的重要工具、Jenkins 是我们打包发布重要工具。一些典型的业务场景说明把业务底层做成 SOA 模块，通过分布式调用框架对外提供服务。后期进行 SOA 到微服务的改造都会涉及。单独做一个小的系统来运行定时任务热点数据放缓存，然后通过 MQ 来更新缓存日志等数据有必要可以考虑上个 Mongo

分布式系统涉及到很多的技术、理论与协议，很多人也说，分布式系统是“入门容易，深入难”，我之前的学习也只算是管中窥豹，只见得其中一斑。因此，一致希望能对分布式系统有一个更全面的认识，至少能够把分布式系统中的各个技术、理论串起来，了解他们在分布式系统分别解决什么问题，有哪些优秀的实现。我曾在网络上搜索过”如何学习分布式系统“，也在知乎上关注了该话题，但并没有看到一个全面的、有指导意义的答案。本文的目标是给打算全面学习分布式系统的自己、以及感兴趣的读者指明一条可行的路径，使得之后的学习不再盲目。不过，我并没有越过这座山，我只是站在山前，从前人留下的痕迹揣测山的全貌与沟壑，臆想的成分居多，还望各位大师指点迷津。2018 03 14更新：对于如何学习分布式系统，经过思考，我觉得有更好的方法，请参见《  分布式学习最佳实践：从分布式系统的特征开始（附思维导图） 》什么是分布式系统分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据 。首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。。。在很多文章中，主要讲分布式系统分为分布式计算（computation）与分布式存储（storage）。计算与存储是相辅相成的，计算需要数据，要么来自实时数据（流数据），要么来自存储的数据；而计算的结果也是需要存储的。在操作系统中，对计算与存储有非常详尽的讨论，分布式系统只不过将这些理论推广到多个节点罢了。那么分布式系统怎么将任务分发到这些计算机节点呢，很简单的思想，分而治之，即分片（ partition）。对于计算，那么就是对计算任务进行切换，每个节点算一些，最终汇总就行了，这就是MapReduce的思想；对于存储，更好理解一下，每个节点存一部分数据就行了。当数据规模变大的时候，Partition是唯一的选择，同时也会带来一些好处：（1）提升性能和并发，操作被分发到不同的分片，相互独立（2）提升系统的可用性，即使部分分片不能用，其他分片不会受到影响理想的情况下，有分片就行了，但事实的情况却不大理想。原因在于，分布式系统中有大量的节点，且通过网络通信。单个节点的故障（进程crash、断电、磁盘损坏）是个小概率事件，但整个系统的故障率会随节点的增加而指数级增加，网络通信也可能出现断网、高延迟的情况。在这种一定会出现的“异常”情况下，分布式系统还是需要继续稳定的对外提供服务，即需要较强的容错性。最简单的办法，就是冗余或者复制集（Replication），即多个节点负责同一个任务，最为常见的就是分布式存储中，多个节点复杂存储同一份数据，以此增强可用性与可靠性。同时，Replication也会带来性能的提升，比如数据的locality可以减少用户的等待时间。下面这种来自  Distributed systems for fun and profit 的图形象生动说明了Partition与Replication是如何协作的。Partition和Replication是解决分布式系统问题的一记组合拳，很多具体的问题都可以用这个思路去解决。但这并不是银弹，往往是为了解决一个问题，会引入更多的问题，比如为了可用性与可靠性保证，引用了冗余（复制集）。有了冗余，各个副本间的一致性问题就变得很头疼，一致性在系统的角度和用户的角度又有不同的等级划分。如果要保证强一致性，那么会影响可用性与性能，在一些应用（比如电商、搜索）是难以接受的。如果是最终一致性，那么就需要处理数据冲突的情况。CAP、FLP这些理论告诉我们，在分布式系统中，没有最佳的选择，都是需要权衡，做出最合适的选择。分布式系统挑战分布式系统需要大量机器协作，面临诸多的挑战：第一，异构的机器与网络：分布式系统中的机器，配置不一样，其上运行的服务也可能由不同的语言、架构实现，因此处理能力也不一样；节点间通过网络连接，而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。怎么保证大家齐头并进，共同完成目标，这四个不小的挑战。第二，普遍的节点故障：虽然单个节点的故障概率较低，但节点数目达到一定规模，出故障的概率就变高了。分布式系统需要保证故障发生的时候，系统仍然是可用的，这就需要监控节点的状态，在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点第三，不可靠的网络：节点间通过网络通信，而网络是不可靠的。可能的网络问题包括：网络分割、延时、丢包、乱序。相比单机过程调用，网络通信最让人头疼的是超时：节点A向节点B发出请求，在约定的时间内没有收到节点B的响应，那么B是否处理了请求，这个是不确定的，这个不确定会带来诸多问题，最简单的，是否要重试请求，节点B会不会多次处理同一个请求。总而言之，分布式的挑战来自 不确定性，不确定计算机什么时候crash、断电，不确定磁盘什么时候损坏，不确定每次网络通信要延迟多久，也不确定通信对端是否处理了发送的消息。而分布式的规模放大了这个不确定性，不确定性是令人讨厌的，所以有诸多的分布式理论、协议来保证在这种不确定性的情况下，系统还能继续正常工作。而且，很多在实际系统中出现的问题，来源于设计时的盲目乐观，觉得这个、那个应该不会出问题。Fallacies_of_distributed_computing很有意思，介绍了分布式系统新手可能的错误的假设：The network is reliable.  Latency is zero.  Bandwidth is infinite.  The network is secure.  Topology doesn't change.  There is one administrator.  Transport cost is zero.  The network is homogeneous.刘杰在《分布式系统原理介绍》中指出，处理这些异常的最佳原则是：在设计、推导、验证分布式系统的协议、流程时,最重要的工作之一就是思考在执行流程的每个步骤时一旦发生各种异常的情况下系统的处理方式及造成的影响。分布式系统特性与衡量标准透明性：使用分布式系统的用户并不关心系统是怎么实现的，也不关心读到的数据来自哪个节点，对用户而言，分布式系统的最高境界是用户根本感知不到这是一个分布式系统，在《Distributed Systems Principles and Paradigms》一书中，作者是这么说的：A distributed system is a collection of independent computers that appearsto its users as a single coherent system.可扩展性：分布式系统的根本目标就是为了处理单个计算机无法处理的任务，当任务增加的时候，分布式系统的处理能力需要随之增加。简单来说，要比较方便的通过增加机器来应对数据量的增长，同时，当任务规模缩减的时候，可以撤掉一些多余的机器，达到动态伸缩的效果可用性与可靠性：一般来说，分布式系统是需要长时间甚至7*24小时提供服务的。可用性是指系统在各种情况对外提供服务的能力，简单来说，可以通过不可用时间与正常服务时间的必知来衡量；而可靠性而是指计算结果正确、存储的数据不丢失。高性能：不管是单机还是分布式系统，大家都非常关注性能。不同的系统对性能的衡量指标是不同的，最常见的：高并发，单位时间内处理的任务越多越好；低延迟：每个任务的平均时间越少越好。这个其实跟操作系统CPU的调度策略很像一致性：分布式系统为了提高可用性可靠性，一般会引入冗余（复制集）。那么如何保证这些节点上的状态一致，这就是分布式系统不得不面对的一致性问题。一致性有很多等级，一致性越强，对用户越友好，但会制约系统的可用性；一致性等级越低，用户就需要兼容数据不一致的情况，但系统的可用性、并发性很高很多。组件、理论、协议假设这是一个对外提供服务的大型分布式系统，用户连接到系统，做一些操作，产生一些需要存储的数据，那么在这个过程中，会遇到哪些组件、理论与协议呢用一个请求串起来用户使用Web、APP、SDK，通过HTTP、TCP连接到系统。在分布式系统中，为了高并发、高可用，一般都是多个节点提供相同的服务。那么，第一个问题就是具体选择哪个节点来提供服务，这个就是负载均衡（loadbalance）。负载均衡的思想很简单，但使用非常广泛，在分布式系统、大型网站的方方面面都有使用，或者说，只要涉及到多个节点提供同质的服务，就需要负载均衡。通过负载均衡找到一个节点，接下来就是真正处理用户的请求，请求有可能简单，也有可能很复杂。简单的请求，比如读取数据，那么很可能是有缓存的，即分布式缓存，如果缓存没有命中，那么需要去数据库拉取数据。对于复杂的请求，可能会调用到系统中其他的服务。承上，假设服务A需要调用服务B的服务，首先两个节点需要通信，网络通信都是建立在TCP/IP协议的基础上，但是，每个应用都手写socket是一件冗杂、低效的事情，因此需要应用层的封装，因此有了HTTP、FTP等各种应用层协议。当系统愈加复杂，提供大量的http接口也是一件困难的事情。因此，有了更进一步的抽象，那就是RPC（remoteproduce call），是的远程调用就跟本地过程调用一样方便，屏蔽了网络通信等诸多细节，增加新的接口也更加方便。一个请求可能包含诸多操作，即在服务A上做一些操作，然后在服务B上做另一些操作。比如简化版的网络购物，在订单服务上发货，在账户服务上扣款。这两个操作需要保证原子性，要么都成功，要么都不操作。这就涉及到分布式事务的问题，分布式事务是从应用层面保证一致性：某种守恒关系。上面说道一个请求包含多个操作，其实就是涉及到多个服务，分布式系统中有大量的服务，每个服务又是多个节点组成。那么一个服务怎么找到另一个服务（的某个节点呢）？通信是需要地址的，怎么获取这个地址，最简单的办法就是配置文件写死，或者写入到数据库，但这些方法在节点数据巨大、节点动态增删的时候都不大方便，这个时候就需要服务注册与发现：提供服务的节点向一个协调中心注册自己的地址，使用服务的节点去协调中心拉取地址。从上可以看见，协调中心提供了中心化的服务：以一组节点提供类似单点的服务，使用非常广泛，比如命令服务、分布式锁。协调中心最出名的就是chubby，zookeeper。回到用户请求这个点，请求操作会产生一些数据、日志，通常为信息，其他一些系统可能会对这些消息感兴趣，比如个性化推荐、监控等，这里就抽象出了两个概念，消息的生产者与消费者。那么生产者怎么讲消息发送给消费者呢，RPC并不是一个很好的选择，因为RPC肯定得指定消息发给谁，但实际的情况是生产者并不清楚、也不关心谁会消费这个消息，这个时候消息队列就出马了。简单来说，生产者只用往消息队列里面发就行了，队列会将消息按主题（topic）分发给关注这个主题的消费者。消息队列起到了异步处理、应用解耦的作用。上面提到，用户操作会产生一些数据，这些数据忠实记录了用户的操作习惯、喜好，是各行各业最宝贵的财富。比如各种推荐、广告投放、自动识别。这就催生了分布式计算平台，比如Hadoop，Storm等，用来处理这些海量的数据。最后，用户的操作完成之后，用户的数据需要持久化，但数据量很大，大到按个节点无法存储，那么这个时候就需要分布式存储：将数据进行划分放在不同的节点上，同时，为了防止数据的丢失，每一份数据会保存多分。传统的关系型数据库是单点存储，为了在应用层透明的情况下分库分表，会引用额外的代理层。而对于NoSql，一般天然支持分布式。一个简化的架构图下面用一个不大精确的架构图，尽量还原分布式系统的组成部分（不过只能体现出技术，不好体现出理论）概念与实现那么对于上面的各种技术与理论，业界有哪些实现呢，下面进行简单罗列。当然，下面的这些实现，小部分我用过，知其所以然；大部分听说过，知其然；还有一部分之前闻所未闻，分类也不一定正确，只是从其他文章抄过来的。罗列在这里，以便日后或深或浅的学习。负载均衡：Nginx：高性能、高并发的web服务器；功能包括负载均衡、反向代理、静态内容缓存、访问控制；工作在应用层LVS：Linux virtual server，基于集群技术和Linux操作系统实现一个高性能、高可用的服务器；工作在网络层webserver：Java：Tomcat，Apache，JbossPython：gunicorn、uwsgi、twisted、webpy、tornadoservice：SOA、微服务、spring boot，django容器：docker，kubernetescache：memcache、redis等协调中心：zookeeper、etcd等zookeeper使用了Paxos协议Paxos是强一致性，高可用的去中心化分布式。zookeeper的使用场景非常广泛，之后细讲。rpc框架：grpc、dubbo、brpcdubbo是阿里开源的Java语言开发的高性能RPC框架，在阿里系的诸多架构中，都使用了dubbo + spring boot消息队列：kafka、rabbitMQ、rocketMQ、QSP消息队列的应用场景：异步处理、应用解耦、流量削锋和消息通讯实时数据平台：storm、akka离线数据平台：hadoop、sparkPS: apark、akka、kafka都是scala语言写的，看到这个语言还是很牛逼的dbproxy：cobar也是阿里开源的，在阿里系中使用也非常广泛，是关系型数据库的sharding + replica 代理db：mysql、oracle、MongoDB、HBase搜索：elasticsearch、solr日志：rsyslog、elk、flume总结写这篇文章，我曾在网络上搜索过“如何学习分布式系统”，但实话说，没有很认同的答案。也许，这确实是一个难以回答的问题。于是，我想自己写出一个答案，但写完这篇文章，感觉自己的回答也很混乱，也没有说清楚，不过对我自己还是有一些指导意义的，比如，理清了分布式系统中会遇到的各种技术、理论、协议，以及通过一个例子展示他们是如何协作的，接下来就是各个击破了。网上的诸多回答，上来就是看各种论文，google三大件、paxos什么的，个人觉得不是很实用。更好的过程，是先有一个整体的把握，然后自己思考会有什么问题，带着问题去寻求答案，在寻求答案的时候再去看论文。另外，也有很多人提到，掌握好计算机基础知识，如操作系统、计算机网络，对学习分布式系统是大有裨益的，这一点我很赞同。分布式系统解决问题的思路是早就有的，很多都是前人研究透的问题，思想都是相同的。比如函数式编程中的map reduce之于Hadoop的MapReduce，比如磁盘存储的raid之于Partition与Replication，比如IPC之于消息队列。