前言
只有光头才能变强。
文本已收录至我的 GitHub 仓库，欢迎 Star：https://github.com/ZhongFuCheng3y/3y
回顾上一篇：
- 《大型网站系统与 Java 中间件》读书笔记（一）
这周周末读了第四章，现在过来做做笔记，希望能帮助到大家。
注：在看这篇文章之前，强烈建议 先看看我之前写过的一篇 SpringCloud 入门文章：外行人都能看懂的 SpringCloud，错过了血亏！。看完再回头看这篇文章，你会发现：这本书讲的设计与实现在 SpringCloud 中几乎都有对应的组件支持。
一、服务框架的设计
从上一篇我们讲到，应用拆开了以后，不同功能 / 模块之间的调用不再单纯通过本机调用，引入了 远程的服务调用。
而远程的服务调用这个东东会很难吗？说白了，不就是两台服务器之间通信吗？
这时候，你能想到什么？必定是 Socket 吧。没错，我们通过 Socket 肯定是可以完成两个系统之间的通信的问题的。（Socket 相信大家在学习基础的时候已经写过 Demo 了，这我就不多 BB 了）
一两个系统的 Socket 写起来没啥，但我们应用拆分之后，系统可是会变得很多很多。
系统很多的情况下，我们在写远程调用代码的时候就可能要考虑到以下的问题：
- 我们肯定是不希望每次远程调用的时候都贴上 重复 的 Socket 代码，要是调用远程方法像调用本地方法一样简单就好了。
- 某个服务应用为了实现高可用，集群了（多台机器部署同一套应用）。那我远程调用的时候 选择 哪一台机器进行调用？
- 网络之间的传输协议用现成的 HTTP 呢？还是自定义一套通信协议呢？
- 因为我们想调用远程方法像调用本地方法一样，那么在网络上就需要传输 Java 对象，要传输 Java 对象，就必须得对其进行 序列化和反序列化的处理。能实现序列化的操作也有很多，选择哪一种方式呢？
- 网络之间的通讯也有 bio、nio、以及 aio 这几种模式，一般来说我们会选择哪种比较多？如果不了解 nio 的同学，可以阅读我以前写过的笔记（nio 你了解多少？）
- …. 等等等
由于系统之间的调用会非常多，我们自然是不希望写重复的代码的，所以 服务框架 （也可以说是 RPC 框架）就应运而生了【说白了就是 专门处理远程服务调用的框架 】。有了服务框架，我们就可以实现多个系统之间以 统一 的方式来进行远程调用了。
- 推荐阅读：RPC 太太太太太太太容易理解啦！
一个 服务框架 需要考虑的问题其实远不止上面所列出的那些，比如说：
- 服务框架与 Web 应用和 Web 容器的关系是什么？服务框架和应用是绑定在一起吗？（服务框架作为 Web 应用的一个依赖包），还是说服务框架只是 Web 应用的一个扩展（没有和 Web 应用打包绑定在一起）
- 服务框架的 jar 包和 Web 应用的 jar 包冲突了怎么办？
- 为了保证系统的稳定性，流量控制也应该要考虑到
- 在远程调用的时候，需不需要以更细粒度的方式来进行选择（之前说的是选择哪台机器，但可以细粒度到机器下的接口或者方法）
- …. 等等
二、服务框架的技术实现思路
在书中给出了设计服务框架时需要考虑的问题的同时也给出了一些实现思路，我摘录一些我觉得比较有参考意义的说说。
2.1 像本地一样调用远程服务
比如服务消费方在执行
orderService.buy("HHKB 键盘")时，实质上调用的是远端的服务。
这用到啥技术？明显就是动态代理（给女朋友讲解什么是代理模式）
在实现的时候有三个基础属性可以参考一下：
- interfaceName— 确定调用的是哪一个接口
- version— 如果接口进行升级了，可以使用 version 来进行区分和隔离
- group— 对远程服务的机器进行分组，那么调用的时候就可以选择不同的分组来调用（调用者对统一服务的调用进行隔离）
2.2 其他
- 当远程调用服务的时候，不需要每次 都要去注册中心查找可用的地址，而是把地址 缓存 在调用方。当服务有变化的时候，主动告诉调用者就行了。
- 流量控制一般会基于两个维度去考虑：一、自身的接口和方法。二、请求的来源
- 并不是所有的请求都要经过服务提供者。像走缓存这样频繁的操作（而且大多数都是会成功的），直接在调用方调用就 ok 了
最后
总的来说，书的第四章主要是在讲解在 设计服务框架的时候应该要考虑到哪些方面，可以以什么方案来解决 ，看得还是非常过瘾的（这只是我的个人笔记，书上还有很多的内容）。 强烈建议 配合我之前写过的一篇 SpringCloud 入门文章：外行人都能看懂的 SpringCloud，错过了血亏！食用。
乐于输出 干货 的 Java 技术公众号：Java3y。公众号内 有 200 多篇原创 技术文章、海量视频资源、精美脑图，关注即可获取！
觉得我的文章写得不错，点 赞！