《大型网站系统与Java中间件》读书笔记 （中）

前言

只有光头才能变强。

文本已收录至个人GitHub仓库，欢迎Star：github.com/ZhongFuChen…

回顾上一篇：

• 《大型网站系统与Java中间件》读书笔记（一）

这周周末读了第四章，如今过来作作笔记，但愿能帮助到你们。

注：在看这篇文章以前，强烈建议先看看我以前写过的一篇SpringCloud入门文章：外行人都能看懂的SpringCloud，错过了血亏！。看完再回头看这篇文章，你会发现：这本书讲的设计与实如今SpringCloud中几乎都有对应的组件支持。

1、服务框架的设计

从上一篇咱们讲到，应用拆开了之后，不一样功能/模块之间的调用再也不单纯经过本机调用，引入了远程的服务调用。

而远程的服务调用这个东东会很难吗？说白了，不就是两台服务器之间通讯吗？

这时候，你能想到什么？一定是Socket吧。没错，咱们经过Socket确定是能够完成两个系统之间的通讯的问题的。（Socket相信你们在学习基础的时候已经写过Demo了，这我就很少BB了）

一两个系统的Socket写起来没啥，但咱们应用拆分以后，系统但是会变得不少不少。

系统不少的状况下，咱们在写远程调用代码的时候就可能要考虑到如下的问题：

1. 咱们确定是不但愿每次远程调用的时候都贴上重复的Socket代码，要是调用远程方法像调用本地方法同样简单就行了。
2. 某个服务应用为了实现高可用，集群了（多台机器部署同一套应用）。那我远程调用的时候选择哪一台机器进行调用？
3. 网络之间的传输协议用现成的HTTP呢？仍是自定义一套通讯协议呢？
4. 由于咱们想调用远程方法像调用本地方法同样，那么在网络上就须要传输Java对象，要传输Java对象，就必须得对其进行序列化和反序列化的处理。能实现序列化的操做也有不少，选择哪种方式呢？
5. 网络之间的通信也有bio、nio、以及aio这几种模式，通常来讲咱们会选择哪一种比较多？若是不了解nio的同窗，能够阅读我之前写过的笔记（nio你了解多少？）
6. ….等等等

因为系统之间的调用会很是多，咱们天然是不但愿写重复的代码的，因此服务框架（也能够说是RPC框架）就应运而生了【说白了就是专门处理远程服务调用的框架】。有了服务框架，咱们就能够实现多个系统之间以统一的方式来进行远程调用了。

• 推荐阅读：RPC太太太太太太太容易理解啦！

一个服务框架须要考虑的问题其实远不止上面所列出的那些，好比说：

• 服务框架与Web应用和Web容器的关系是什么？服务框架和应用是绑定在一块儿吗？（服务框架做为Web应用的一个依赖包），仍是说服务框架只是Web应用的一个扩展（没有和Web应用打包绑定在一块儿）
• 服务框架的jar包和Web应用的jar包冲突了怎么办？
• 为了保证系统的稳定性，流量控制也应该要考虑到
• 在远程调用的时候，需不须要以更细粒度的方式来进行选择（以前说的是选择哪台机器，但能够细粒度到机器下的接口或者方法）
• ....等等

2、服务框架的技术实现思路

在书中给出了设计服务框架时须要考虑的问题的同时也给出了一些实现思路，我摘录一些我以为比较有参考意义的说说。

2.1 像本地同样调用远程服务

好比服务消费方在执行orderService.buy("HHKB键盘")时，实质上调用的是远端的服务。

这用到啥技术？明显就是动态代理（给女友讲解什么是代理模式）

在实现的时候有三个基础属性能够参考一下：

• interfaceName— 肯定调用的是哪个接口
• version— 若是接口进行升级了，可使用version来进行区分和隔离
• group— 对远程服务的机器进行分组，那么调用的时候就能够选择不一样的分组来调用（调用者对统一服务的调用进行隔离）

2.2 其余

1. 当远程调用服务的时候，不须要每次都要去注册中心查找可用的地址，而是把地址缓存在调用方。当服务有变化的时候，主动告诉调用者就好了。
2. 流量控制通常会基于两个维度去考虑：1、自身的接口和方法。2、请求的来源
3. 并非全部的请求都要通过服务提供者。像走缓存这样频繁的操做（并且大多数都是会成功的），直接在调用方调用就ok了

最后

总的来讲，书的第四章主要是在讲解在设计服务框架的时候应该要考虑到哪些方面，能够以什么方案来解决，看得仍是很是过瘾的（这只是个人我的笔记，书上还有不少的内容）。强烈建议配合我以前写过的一篇SpringCloud入门文章：外行人都能看懂的SpringCloud，错过了血亏！食用。

乐于输出干货的Java技术公众号：Java3y。公众号内有200多篇原创技术文章、海量视频资源、精美脑图，关注便可获取！

以为个人文章写得不错，点赞！