回顾上一篇:
《大型网站系统与Java中间件》读书笔记(一)
这周周末读了第四章,现在过来做做笔记,希望能帮助到大家。
一、服务框架的设计
从上一篇我们讲到,应用拆开了以后,不同功能/模块之间的调用不再单纯通过本机调用,引入了远程的服务调用。
而远程的服务调用这个东东会很难吗?说白了,不就是两台服务器之间通信吗?
这时候,你能想到什么?必定是Socket吧。没错,我们通过Socket肯定是可以完成两个系统之间的通信的问题的。(Socket相信大家在学习基础的时候已经写过Demo了,这我就不多BB了)
一两个系统的Socket写起来没啥,但我们应用拆分之后,系统可是会变得很多很多。
系统很多的情况下,我们在写远程调用代码的时候就可能要考虑到以下的问题:
1.我们肯定是不希望每次远程调用的时候都贴上重复的Socket代码,要是调用远程方法像调用本地方法一样简单就好了。
某个服务应用为了实现高可用,集群了(多台机器部署同一套应用)。
2.那我远程调用的时候选择哪一台机器进行调用?
网络之间的传输协议用现成的HTTP呢?还是自定义一套通信协议呢?
3.因为我们想调用远程方法像调用本地方法一样,那么在网络上就需要传输Java对象,要传输Java对象,就必须得对其进行序列化和反序列化的处理。能实现序列化的操作也有很多,选择哪一种方式呢?
4.网络之间的通讯也有bio、nio、以及aio这几种模式,一般来说我们会选择哪种比较多?如果不了解nio的同学,可以阅读我以前写过的笔记(nio你了解多少?)
….等等等
由于系统之间的调用会非常多,我们自然是不希望写重复的代码的,所以服务框架(也可以说是RPC框架)就应运而生了【说白了就是专门处理远程服务调用的框架】。有了服务框架,我们就可以实现多个系统之间以统一的方式来进行远程调用了。
一个服务框架需要考虑的问题其实远不止上面所列出的那些,比如说:
1.服务框架与Web应用和Web容器的关系是什么?服务框架和应用是绑定在一起吗?(服务框架作为Web应用的一个依赖包),还是说服务框架只是Web应用的一个扩展(没有和Web应用打包绑定在一起)
2.服务框架的jar包和Web应用的jar包冲突了怎么办?
2.为了保证系统的稳定性,流量控制也应该要考虑到
在远程调用的时候,需不需要以更细粒度的方式来进行选择(之前说的是选择哪台机器,但可以细粒度到机器下的接口或者方法)
…等等
最后
总的来说,书的第四章主要是在讲解在设计服务框架的时候应该要考虑到哪些方面,可以以什么方案来解决,看得还是非常过瘾的