22 利用分布式服务打造可复用的业务平台

1. 编译、部署困难：对于网站开发工程师而言，打包构建一个巨型应用是一件痛苦 的事情，也许只是修改了一行代码，输入build命令后，抽完一支烟， building；又去喝了一杯水，回来一看，还在building；又去了一次厕所， building；好不容易build结束，一看编译失败，还得重来

2. 代码分支管理困难：复用的代码模块由多个团队共同维护修改，候总会发生冲突。代码merge一般发生在网站发布的时候，经常和发布过程中出现的其他 问题互相纠结在一起，顾此失彼，导致每次发布都要拖到半夜三更。

3. 数据库连接耗尽：巨型的应用、大量的访问，必然需要将这个应用部署在一个大 规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，以每个应用10个连 接计，一个数百台服务器集群的应用将需要在数据库上创建数千个连接。数据库服务器 上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一 般的数据操作。

4. 新增业务困难：想要在一个已经如乱麻般的系统中增加新业务，维护旧功能，难度可想而知：一脚踩进去，发现全都是雷，什么都不敢碰。许多新工程师来公司半年了, 还是不能接手业务，因为不知道水有多深。于是就出现这种怪现象：熟悉网站产品的“老 人”忙得要死，加班加点干活；不熟悉网站产品的新人一帮忙就岀乱，跟着加班加点;整个公司热火朝天，加班加点，却还是经常出故障，新产品迟迟不能上线。

解决方案就是拆分，将模块独立部署，降低系统耦合性。拆分可以分为纵向拆分和 横向拆分两种。

纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接 将其设计部署为一个独立的Web应用系统。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用 这些分布式服务，不需要依赖具体的模块代码，即可快速搭建一个应用系统，而模块内业务逻辑变化的时候，只要接口保持一致就不会影响业务程序和其他模块。如图7.4所示。

纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离，使其成为独立的 Web应用。而对于横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务依 赖关系，还需要一个完善的分布式服务管理框架。

---

1 Web Service与企业级分布式服务

Web Service曾经是企业应用系统开发领域最时髦的词汇之一，用以整合异构系统及 构建分布式系统。Web Service原理架构如图7.5所示。

服务提供者通过WSDL （ Web Services Description Language, Web服务描述语言）向 注册中心（Service Broker ）描述自身提供的服务接口属性，注册中心使用UDDI（ Universal Description, Discovery, and Integration,统一描述、发现和集成）发布服务提供者提供的服 务，服务请求者从注册中心检索到服务信息后，通过SOAP （ Simple Object Access Protocol,简单对象访问协议）和服务提供者通信，使用相关服务。

Web Service虽然有成熟的技术规范和产品实现，并在企业应用领域有许多成功的案 例，但也有如下固有的缺点。

1. 臃肿的注册与发现机制。

2. 低效的XML序列化手段。

3. 开销相对较高的HTTP远程通信。

4. 复杂的部署与维护手段。

这些问题导致Web Service难以满足大型网站对系统高性能、高可用、易部署、易维 护的要求。

---

2 大型网站分布式服务的需求与特点

对于大型网站，除了 Web Service所提供的服务注册与发现，服务调用等标准功能， 还需要分布式服务框架能够支持如下特性。

负载均衡

对热门服务，比如登录服务或者商品服务，访问量非常大，服务需要部署在一个集 群上。分布式服务框架要能够支持服务请求者使用可配置的负载均衡算法访问服务，使 服务提供者集群实现负载均衡。

失效转移

可复用的服务通常会被多个应用调用，一旦该服务不可用，就会影响到很多应用的 可用性。因此对于大型网站的分布式服务而言，即使是很少访问的简单服务，也需要集 群部署，分布式服务框架支持服务提供者的失效转移机制，当某个服务实例不可用，就 将访问切换到其他服务实例上，以实现服务整体高可用。

高效的远程通信

对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通 信手段，服务调用会成为整个系统性能的瓶颈。

整合异构系统

由于历史发展和组织分割，网站服务可能会使用不同的语言开发并部署于不同的平 台，分布式服务框架需要整合这些异构的系统。

对应用最少侵入

网站技术是为业务服务的，是否使用分布式服务需要根据业务发展规划，分布式服 务也需要渐进式的演化，甚至会岀现反复，即使用了分布式服务后又退回到集中式部署,分布式服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式 部署，也可分布式部署。

版本管理

为了应对快速变化的需求，服务升级不可避免，如果仅仅是服务内部实现逻辑升级, 那么这种升级对服务请求者而言是透明的，无需关注。但如果服务的访问接口也发生了 变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系 统可以申请停机维护，同时升级接口。但是网站服务不可能中断，因此分布式服务框架 需要支持服务多版本发布，服务提供者先升级接口发布新版本的服务，并同时提供旧版 本的服务供请求者调用，当请求者调用接口升级后才可以关闭旧版本服务。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Java）

Spring全套教学资料

Spring是Java程序员的《葵花宝典》，其中提供的各种大招，能简化我们的开发，大大提升开发效率！目前99%的公司使用了Spring，大家可以去各大招聘网站看一下，Spring算是必备技能，所以一定要掌握。

目录：

部分内容：

Spring源码

• 第一部分 Spring 概述
• 第二部分 核心思想
• 第三部分 手写实现 IoC 和 AOP（自定义Spring框架）
• 第四部分 Spring IOC 高级应用
  基础特性
  高级特性
• 第五部分 Spring IOC源码深度剖析
  设计优雅
  设计模式
  注意：原则、方法和技巧
• 第六部分 Spring AOP 应用
  声明事务控制
• 第七部分 Spring AOP源码深度剖析
  必要的笔记、必要的图、通俗易懂的语言化解知识难点

脚手框架：SpringBoot技术

它的目标是简化Spring应用和服务的创建、开发与部署，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用的微服务功能，可以和spring cloud联合部署。

Spring Boot的核心思想是约定大于配置，应用只需要很少的配置即可，简化了应用开发模式。

• SpringBoot入门
• 配置文件
• 日志
• Web开发
• Docker
• SpringBoot与数据访问
• 启动配置原理
• 自定义starter

微服务架构：Spring Cloud Alibaba

同 Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

• 微服务架构介绍
• Spring Cloud Alibaba介绍
• 微服务环境搭建
• 服务治理
• 服务容错
• 服务网关
• 链路追踪
• ZipKin集成及数据持久化
• 消息驱动
• 短信服务
• Nacos Confifig—服务配置
• Seata—分布式事务
• Dubbo—rpc通信

Spring MVC

目录：

部分内容：

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
99534241)]

部分内容：

[外链图片转存中…(img-IhoCWIjF-1713799534241)]

[外链图片转存中…(img-a4pHj5F9-1713799534241)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！