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