想做分布式开发，需要懂哪些技术？

╰+攻爆jí腚メ 2022-12-12 15:10 134阅读 0赞

【**阅读建议**】文章多处链接别处详细文章，客观莫急建议先把文章总体阅读完毕后，再点进去慢慢品味具体细节点。

--------------------

### 一、前言 ###

私底下问了几位前同事，还有不少同行的大学同学，几乎他们公司都在用目前主流的分布式技术框架做开发。还记得几年前刚毕业那会，.net和php做各种企业管理系统和网站还很吃香，智能机普及安卓和ios客户端开发大势流行更胜一筹；硬件方面C作为底层开发的鼻祖，网游和手游风靡之下C++作为主流游戏服务端语言；再看看Java虽是不温不火，却仍然是应用最广泛的开发语言，从传统行业到通信和金融、再到移动互联网、支付和电商等；在各种技术框架下，仍然用着Java作为第一开发语言。今天，想做分布式开发，需要掌握的技术知识点也是非常得多。如果你所在的公司正在往分布式技术栈迁移，或者你自己有往这方面学习和深入的打算，而又有点迷茫不知从何学期。那么，接下来就让我们一起来看看，想做分布式开发，到底需要学会哪些技术？

### 二、分布式篇 ###

首先，我们从整体的架构开始进行一个初步的认识。我们先来思考以下几个问题，从各个层面来一一剖析分布式技术框架，让你全面了解分布式框架知识。

**1 这个技术框架，它是什么东西？**

对于还没接触和了解过分布式框架的朋友，这个问题是你要关注的。你要学习一个东西总得先学习和了解它吧。详细查看博主另一篇文章，非常详细和形象的表述了单体式架构和分布式框架的区别，以类比法让你不仅掌握了分布式框架知识，而且还能同时比较单体式架构跟分布式架构的区别：[单体架构，分布式系统的差别在哪里？][Link 1]

**2 这个技术框架，它为解决了什么问题或痛点？**

传统的单体式架构，存在团队合作困难。每次需求迭代和修改，即使是修改一行代码，也将涉及到整个系统的打包部署。不仅给开发和测试带来更多额外工作，也给运营带来困扰需要停机维护。另一个，从系统层面上来讲。单体式架构系统代码臃肿，高内聚高耦合应对高并发时有明显的系统性能缺陷，需要依赖机器服务集群部署来弥补软件性能的劣势。这时，分布式就应运而生了，它有着明显的优势：高内聚、低耦合，团队协作，各个业务模块独立开发测试和部署；完全避免和解决了单体式架构的缺陷与问题。这篇文章也有详细说明：[分布式框架解决了什么问题？][Link 1]

**3 有哪些分布式框架技术？**

目前主流的分布式技术除了SpringBoot/Cloud、Dubbo外，像腾讯的Tars，京东的JSF，新浪的Motan等；SpringBoot/Cloud是国际性应用最广发的分布式框架技术，而国内也有很多互联网公司使用国产的Dubbo和Motan框架；Dubbo是阿里巴巴开源的一个RPC（远程过程调用）架构，Motan是新浪开源的轻量级RPC框架。

**4 掌握这个技术框架，需要学会哪些（多少）技术？**

要学习分布式技术框架，除了需要有坚实的Java基础外，还得掌握很多分布式组件知识。接下来就把本文的重点奉献给大家：  
**4.1 分布式服务框架**

主要分为HTTP和RPC两种类型，面向服务架构SOA，它是一种建设企业生态系统的架构指导思想。SOA的关注点是服务，服务最基本的业务功能是单元，由平台中立性的接口契约来定义。通过将业务系统服务化、不同模块解耦、各模块间互相调用、消息交换和资源共享。

主流的分布式/微服务架构：SpringBoot/Cloud、Dubbo、Tars、JSF、Motan等。

**4.2 分布式事务**

事物的4个基本特性：原子性、一致性、隔离性和持久性。

CAP原则和BASE理论，详细见博文：[分布式CAP理论和BASE理论][CAP_BASE]

XA协议通过2PC两阶段提交，三阶段提交3PC解决方案。

TCC模式（Try、Confirm、Cancle）最终一致性分布式事务的实现方案：[谈谈分布式事务TCC机制][TCC]

补偿模式如重试机制达到最终一致性。

可靠事件模式通过异步处理、系统解耦、流量削峰等：[消息中间件MQ系列][MQ]

开源方案有：tcc-tranction、Elastic-Job、ShardingSphere、seata、MQ。

**4.3 分布式锁**

*  在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行。
 *  高可用的获取锁与释放锁
 *  高性能的获取锁与释放锁
 *  具备可重入特性（可理解为重新进入，由多于一个任务并发使用，而不必担心数据错误）
 *  具备锁失效机制，防止死锁
 *  具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败

经典方案：基于zookeeper或者redis实现分布式锁。

**4.4 分布式缓存**

分布式缓存是为了解决web服务器与数据库服务器之间的瓶颈，如果访问流量大，那么这个瓶颈就越大。数据库的读取压力将会非常大，即使此时数据库已经做了读写分离。那么为了分担数据库的压力，需要将数据缓存起来，这是可以在业务层，缓存数据。

经典方案：redis、memcache 实现。

**4.5 分布式消息系统**

主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构(分布式事务)。

经典方案：Kafka、ActiveMQ、RabbitMQ、RocketMQ （详见文章）[消息中间件MQ系列][MQ]   [Zookeeper搭载kafka消息发布和订阅][Zookeeper_kafka]

**4.6 分布式搜索系统**

在*分布式*的环境中，利用*分布式*计算和移动代理等技术从大量的、异构的信息资源中检索出对于用户有用的信息的过程。分布式环境指的是信息资源在物理上分布于不同的地点，在数据库结构上具有异构性，这些分散和异构的信息资源在逻辑上是一个整体，从而构成一个分布式检索系统。

经典解决方案：Elasticsearch（基于Luence）

**4.7 分布式调度**

任务调度是指基于给定的时间点，给定的时间间隔或者给定执行次数自动的执行任务。任务调度是是操作系统的重要组成部分，而对于实时的操作系统，任务调度直接影响着操作系统的实时性能。任务调度涉及到多线程并发、运行时间规则定制及解析、线程池的维护等诸多方面的工作。

分布式任务调度框架：cronsun、Elastic-job、saturn、lts、TBSchedule、xxl-job等

**4.8 配置中心**

随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：

*  安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏。
 *  时效性：修改配置，需要重启服务才能生效。
 *  局限性：无法支持动态调整：例如日志开关、功能开关。

常见分布式配置中心：Spring config 、Apollo 、nacos、Diamond、Disconf  （详见）[SpringCloud-Config配置中心学习总结][SpringCloud-Config]

**4.9 注册中心**

注册中心主要涉及到三大角色：

1.  服务提供者
2.  服务消费者
3.  注册中心

关系大致如下：

*  各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。
 *  服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。
 *  各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。
 *  微服务网络地址发送变化（例如实例增加或IP变动等）时，会重新注册到注册中心。这样，服务消费者就无需人工修改提供者的网络地址了。

主要解决方案：Zookeeper、Eureka、Nacos、Consul

**4.10 分布式链路追踪**

分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、分布式数据库、分布式缓存等，使得后台服务构成了一种复杂的分布式网络。在服务能力提升的同时，复杂的网络结构也使问题定位更加困难。在一个请求在经过诸多服务过程中，出现了某一个调用失败的情况。

分布式链路追踪就是将一次分布式请求还原成调用链路，将一次分布式请求的调用情况集中展示，比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

解决方案：Zipkin、Brave、Dapper、CAT、Mtrace等

**4.11 服务监控**

分布式系统复杂，需要有一个监控来将整个应用调用的全过程进行全天候监控，也能对系统资源、第三方组件进行监控，确保能够第一时间发现问题并及时解决问题。

*  web地址响应性能监控与统计
 *  服务响应新能监控与统计
 *  RPC服务响应性能监控与统计
 *  API接口响应性能监控与统计
 *  组件节点监控（MySQL、Redis、MQ）
 *  系统CPU、内存、硬件监控
 *  系统异常监控与统计

解决方案：Zabbix、Nagios、Metrics、Spectator

**4.12 日志收集和分析**

集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，分布式日志手机解决更高的查询、排序和统计。

主要组件：FileBeat + Kafka + ELK（Logstash）、Flume

**4.13 服务路由网关**

路由网关的角色是作为一个API架构，用来保护、增强和控制对于API服务的访问，它处于应用程序或服务之前的系统，用来管理授权、访问控制和流量限制等。

四大路由网关：Zuul 2、SpringCLoud Gateway、Kong、OpenResty （详见文章）[这些微服务网关你了解吗？][Link 2]

**4.14 服务熔断器**

复杂的分布式架构的应用程序有很多依赖，都会不可避免的出现服务故障等问题。高并发的依赖失败时，如果没有采取措施，当前应用服务就有被拖垮的风险。

当下游服务因为访问压力过大或者其他原因导致影响变慢的时候，上游服务为了保护自己以及系统整体的可用性，可以暂时切断对下游服务的调用。

解决方案：Hystrix、Envoy

**4.15 负载均衡**

一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。

我们通常说的负载均衡都是指web服务端负载均衡，但是涉及到分布式系统时，就不是简单的服务端负载均衡了，一般都需要在各个业务系统间维护一个客户端的负载均衡机制。

服务端负载均衡：Nginx 、OpenResty

客户端负载均衡：Ribbon和Feign

详见文章：[Ribbon和Feign客户端负载均衡及服务调用][Ribbon_Feign]

### 三、总结 ###

分布式技术栈是一个复杂和庞大的体系，每一个知识点都博大精深，想要深入精髓达到精通的境界难度非常大。但我们只需要达到掌握其基本理论和一些常用技术点，用以解决日常工作中的问题就足够了。

以上所有组件技术都收录在了公众号：[SpringCloud微服务构建浅析][SpringCloud]

--------------------

既然都看完了整篇文章，相信对你一定有所帮助。原创不易，远离伸手党。

点击下方【打赏】小编，或者关注公众号给予支持，你们的每一份鼓励都将是小编伟大的动力。

--------------------

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZvbGxvd18yNA_size_16_color_FFFFFF_t_70][] 同名原创公众号：   **程序大视界**

[Link 1]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247484196&idx=1&sn=481f878daa46a77ded18f8681ee3884e&chksm=fb3eb051cc493947b039cffaad3d02fc49087c6ec249b839bcd6c326ebb3bdc140480a32bf18&token=2008267728&lang=zh_CN#rd
[CAP_BASE]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247483902&idx=1&sn=ebcf276091acc5b0323701cf91d9180e&chksm=fb3eb28bcc493b9dd94015774f17724d1d7fca9d10e7bbed2e456d18c627b1ab31a02633f921&token=2008267728&lang=zh_CN#rd
[TCC]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247483822&idx=1&sn=82479762423748beab6383be6423ef59&chksm=fb3eb2dbcc493bcd38822b1f8a568724123c7c103ecd38ed8f744f55b057b45f4924242affe8&token=2008267728&lang=zh_CN#rd
[MQ]: https://blog.csdn.net/xuri24/article/details/88554233
[Zookeeper_kafka]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247483908&idx=1&sn=e3c1b6aac82a64de11aee174d4fbc545&chksm=fb3eb171cc493867e97272b135fa61892b33da15274948e5e3e50dbed382c54267254011f4bf&token=2008267728&lang=zh_CN#rd
[SpringCloud-Config]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247483847&idx=1&sn=081fc6c3c6c8d1bfb22b643000c28247&chksm=fb3eb2b2cc493ba481c51ae5610cb1ceedb16560275bd07f5e17b8766d8c6cfa7dde34e1e7ea&token=2008267728&lang=zh_CN#rd
[Link 2]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247484220&idx=1&sn=085a04754f60ed918185375c833d1f2a&chksm=fb3eb049cc49395f89d4c709d196e7d97336f770782cdc7ae2150f1e6050a18dde82d7f1957b&token=2008267728&lang=zh_CN#rd
[Ribbon_Feign]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247484210&idx=1&sn=cde94139008c9070d5d8a2b63996fcee&chksm=fb3eb047cc493951321c442a03843e21fbe2d22870ea4f47ccc03604ee6e9d6e188de1f30341&token=2008267728&lang=zh_CN#rd
[SpringCloud]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247483732&idx=1&sn=2a3b1c05220efc6ed9bc6dede60bf5b1&chksm=fb3eb221cc493b3752dfb6e0a30c843761c722eed43c5471461ff91d00c04dc5199de0157bca&token=2008267728&lang=zh_CN#rd
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZvbGxvd18yNA_size_16_color_FFFFFF_t_70]: /images/20221123/2fc0c874f4e341e5af44d77ed60ebb49.png