极客大学架构师训练营 微服务架构 Service Mesh 服务网格 RPC 协议实现原理 Dubbo 通讯协议 第19课 听课总结
说明
讲师：李智慧
阿里早期微服务架构重构
单体应用，所有的服务都在一个War包里面发布，体积大约1.2G。
巨无霸应用系统带来的问题
编译、部署困难：
- 对于网站开发工程师而言，打包构建一个巨型应用是一件痛苦的事情。
- 也许只是修改了一行代码，输入 build 命令后，抽完一支烟，回来一看，还在 building；
- 又去喝了一杯水，回来一看，还在building；
- 又去了一次厕所，回来一看，还在building；
- 好不容易build 结束，一看编译失败，还得重来…
- 想砸了显示器有木有？
代码分支管理困难：
- 复用的代码模块由多个团队共同维护修改，代码 merge 的时候总会发生冲突。
- 代码 merge 一般在网站发布的时候，和发布等问题互相纠结在一起，顾此失彼，每次发布都要半夜三更。
数据库连接耗尽：
- 巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，以每个应用10个连接计，一个数百服务器集群的应用将需要在数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一般的数据操作。
新增业务困难：
- 想要在一个已经乱如麻般系统中增加新业务，维护旧功能，难度可想而知。
- 一脚踩进去，发现全都是雷，什么都不敢碰。许多新工程师来公司半年了，还是不能接受业务，因为不知道水有多深。
- 于是就出现这种怪现象：熟悉网站产品的“老人” 忙得要死，加班加点干活；不熟悉网站产品的工程师一帮忙就出乱，跟着加班加点；
- 整个公司热火朝天，加班加点，却还是经常出故障，新产品迟迟不能上线。
解决方案就是拆分，将模块独立部署，降低系统耦合性：
解决方案就是拆分，将模块独立部署，降低系统耦合性：
- 纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。
- 横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。
微服务框架
Web Service 与企业级分布式服务
- Service Provider: 服务提供者
- Service Requester：服务消费者，客户端
- Service Broker：服务注册中心。服务提供者注册服务到服务注册中心；服务消费者从服务注册中心请求服务，服务注册中心调用服务提供者，最终把结果返回给服务消费者。
数据格式是：XML，XML一半的数据都是冗余的，性能比较低下。
服务提供者通过 WSDL （Web服务描述语言，Web Services Description Language）向注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用 UDDI (Universal Description, Discovery, and Integration, 统一描述、发现和集成)发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过 SOAP (Simple Object Access Protocol, 简单对象访问协议) 和服务提供者通信，使用相关服务。
Web Service 虽然有着成熟的技术规范和产品实现，以及在企业应用领域有许多成功的案例，但是也具有一些固有的缺点：
- 臃肿的注册和发现机制；
- 低效的 XML 序列化手段；
- 开销相对高的 HTTP 远程通信；
- 复杂的部署和维护手段；
这些问题导致 Web Service 难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。
微服务框架需求
对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：
- 失效转移(Fail Over): 对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。
- 负载均衡：对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。
- 高效的远程通信： 对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。
- 对应用最少侵入： 网站技术是为业务服务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。
- 版本管理：为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务器调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。（阿里的对升级以后服务维护半年，半年以后就下线。）
微服务架构 (Dubbo)
- 服务提供者 注册到 服务注册中心，把服务映射到服务提供者列表；
- 服务消费者程序，调用服务接口；
- 接口访问代理获取到服务消费者调用的接口；
- 服务框架客户端，调用服务提供者列表找到服务提供者；
- 负载均衡策略分配一个服务给服务框架客户端；
- 远程通讯模块与客户端建立连接；
- 远程通信模块，调用 服务调用线程；
- 服务调用线程 请求服务提供者程序， 服务提供者程序返回服务的 class 给服务调用线程；
- 服务调用线程 返回 class 给远程通讯模块；
- 远程通讯模块 返回 class 给 服务框架客户端， 服务框架客户端 用 class 创建对象，调用里面的方法即可。
Service Mesh 服务网格
Service Mesh 是一个基础设施层，用于处理服务间的通信，通常变现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。
Service Mesh的Sidecar模式
火过一阵子，实际应用收益不是很大。
微服务架构实践
微服务架构落地
- 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。
- 先有独立的模块，后有分布式的服务。
- 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。
- 要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？
命令与查询职责隔离 （CQRS）
在服务接口层面将查询(读操作) 与命令 (写操作) 隔离，实现服务层的读写分离。
- 更清晰的领域模型；
- 针对读写分别优化，实现更好的性能；
- 查询服务不会修改数据，更好地保护数据。
事件溯源
将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。
- 利用事件溯源，可以精确复现任何用户状态，进行复核审计。
- 利用事件溯源，可以有效监控用户状态变化，并在此基础上实现分布式事务。
断路器
当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务器级联失效，这种情况下使用断路器阻断对故障服务的调用。
- 断路器三种状态：关闭，打开，半开。
服务重试及调用超时
上游调用者超时时间要大于下游调用者超时时间之和。
最重要的是需求
最重要的是需求。
RPC 协议实现原理
远程过程调用 (RPC)
通信协议（Communications Protocol）
通讯协议在电信领域中是指任何物理介质中允许两个或多个在传输系统中的终端之间传播信息的系统标准，也是指计算机通信或者网络设备的共同语言。
一个完整的应用层通信协议通常包含两个部分：
- 网络通信协议：TCP、UDP
- 编码传输协议：二进制、文本
为什么设计私有通讯协议？
- 充分并有效利用通讯协议里的每个字段，减少冗余数据传输。
- 灵活满足自定义通讯需求，例如 CRC 检验、Server Fail-fast、自定义序列化器。
- 最大程度满足性能需求：IO 模型和线程模型的充分利用。
常见的私有协议模式
Dubbo 通讯协议
org.apache.dubbo.remoting.exchange.codec.ExchangeCode
Dubbo 通讯协议-解码 Response 对象
org.apache.dubbo.rpc.protocol.dubbo.DubboCodec
Dubbo 通讯协议 - 解码 Request 对象
Dubbo 利用 requestId 避免对头阻塞
requestId：请求 ID，该字段主要用于异步请求时，保留请求存根使用，便于响应回来时出发回调。另外，在日志打印与问题调试时，也需要该字段。
SOFA-RPC 通讯协议 （Bolt 协议）- 请求命令
SOFA-RPC 通讯协议 （Bolt 协议）- 响应命令
SOFA-RPC 通讯协议 （Bolt 协议）
com.alipay.remoting.rpc.protocol.RpcCommandEncoderV2
序列化协议
总结
有些团队加班特别狠，最终整个项目失败了。
不要用战术上的勤奋，掩盖战略上的懒惰。
微服务的关键点不在技术，搞不清楚业务，搞不清楚模块的边界，就只有死路一条。先把逻辑关系，耦合关系理顺了，业务开发人员、微服务维护人员、产品经理职责要理顺，目标不清楚，就不要搞微服务。
极客大学架构师训练营 微服务架构 Service Mesh 服务网格 RPC 协议实现原理 Dubbo 通讯协议 第19课 听课总结相关推荐
- 极客大学产品经理训练营：业务架构与概念模型 第10课总结
讲师:邱岳 1. 什么是状态图 系统中的概念或对象随着一些事件的发生,改变了状态,通常这个状态比较多.比较复杂时,我们需要用状态图来表示他们的边界,以及触发状态转换的活动. 2. 动手画 – 员工状态 ...
- .NET 云原生架构师训练营（系统架构）--学习笔记
▲ 点击上方"DotNet NB"关注公众号 回复"1"获取开发者路线图 学习分享 丨作者 / 郑 子 铭 这是DotNet NB 公众号的第176篇原创文章 ...
- 极客大学产品经理训练营：数据分析与商业分析，商业分析到业务分析 第18课总结
讲师:邱岳 1. 产品经理眼中的利润.成本.收入 利润 = 收入 - 成本 奶茶利润率极高,达到60%左右.但是奶茶盈利比较难. 所有买水的产品利润率都极高,比如可口可乐,咖啡,奶茶等. 案例:有个面 ...
- 极客大学产品经理训练营 产品文档和原型 作业4
作业 [本周作业]写一个用例,挑一个:你自己的产品 / 你喜欢的产品 / [拍东西]发起拍卖/ [知识星球]加入星球/ [极客时间]购买课程: 1. 标题作者修改历史 标题:[极客时间]购买课程 作者 ...
- 极客大学产品经理训练营：业务流程与产品文档 第11课总结
讲师:邱岳 1. 原型图 1.1 手绘图 + Scanner Pro 1.2 线框图 1.3 高保真产品图 1.4 做原型图的目的 坍缩:规划时梦到自己成了乔布斯,赶紧画个图让自己冷静冷静: 具体:具 ...
- 极客大学产品经理训练营：产品文档和原型咋弄 - 流程图 第9课总结
讲师:邱岳 1. 图的意义 流程图.活动图.时序图.状态图,本次聚焦于过程和行为描述. 提效.宏观.点睛. 梳理思路 用例:做什么? 流程图:怎么做? 2. 流程图.活动图.时序图 3. 动手画 – ...
- 极客大学产品经理训练营 极客时间购买课程-大作业
1. 标题作者修改历史 标题:[极客时间]购买课程 作者 历史 时间 易筋 创建 2021-01-09 易筋 添加购买流程图6 2021-03-02 易筋 添加购买时序图7 2021-03-16 2. ...
- 极客大学产品经理训练营：产品经理的职业规划 第20课总结
讲师:邱岳 1. 简历(你)作为产品 简历可能是你向你未来同事展示的第一个作品,关于你自己的经历.特点.审美,所以要像设计和研发一个产品那样设计好你的简历. 当谈论产品的时候,我们的思路应该依然是:用 ...
- 极客大学产品经理训练营：运营思维 第19课总结
讲师:邱岳 1. 运营是做什么的 运转·经营. 产品经理经常拆房子.盖新房子.经营是要持续经营一个产品. CEO.COO(Apple 的Tim Cook以前就是).CTO.CFO.CIO- 运营其实是 ...
- 极客大学产品经理训练营 解决方案的设计与积累 第6课总结
说明 讲师:邱岳(二爷) 1. 解决方案 解决方案的前提是明确了 利益相关者 和 待解决的问题 出解决方案是产品经理的天职,不要直接转发 注意 X-Y Problem,核心关注 X 大量的练习/模仿/ ...
最新文章
- android 悬停按钮,Android悬浮按钮的使用方法
- 常用前端框架Angular和React的一些认识
- kubernetes一次生产故障日记
- List转DataTable(反射)
- 2022的第一天，立个目标
- [原创]Clang with Microsoft CodeGen小测试
- DNS服务器配置详解
- Atitit 数据库视图与表的wrap与层级查询规范
- php存库,php – 使用Laravel实现存储库模式
- 基于RV1126平台imx291分析 --- media部件注册 rkcif_mipi
- python物理建模初学者指南 pdf下载_Python物理建模初学者指南
- C语言字母O和数字0怎么区分,车牌数字“0”和字母“O”究竟如何区分？看完终于弄明白了...
- 人工智能的数学基础------- 矩阵迹与相似矩阵的本质
- tig只看某个作者的提交
- c语言long型是什么,c语言long类型是什么意思
- 沙盒型源码安全解决方案
- 生物蛋白质数据库类型【总结】
- 澳大利亚政府为区块链能源项目拨款800万澳元
- 使用视频监控摄像头的语音对讲功能，在视频平台，配置符合GB28181协议国标视频对讲
- 【游戏程序设计】完整二维游戏开发-飞机大战