大型网站系统与Java中间件实践 第4章 服务框架

为什么需要服务化

数据库连接数带来的压力
应用复杂臃肿，还有一些代码冗余，影响开发效率

前期的解决方案： 把应用拆小，但是数据库的压力还在，一些公用的代码还是可能存在冗余，当前也可以使用共享库的方式解决，应用起来不太方便。

服务化能够解决哪些问题

系统架构更加清晰
专门的团队负责自己的服务，提高代码质量，由于核心相对稳定，修改和发布的次数会减少，也会提供稳定性
更加底层的资源统一由服务层管理，结构更加清晰，利于提高效率。

服务化需要解决哪些问题

服务可能是多层的，服务之间也可能相互调用在，这就需要服务治理。

如何实施服务化

寻址

名称服务
规则服务器

序列化

常用的参数

version ：加入版本号控制
group : 分组，如果同一个接口的远程服务有很多机器，我们就可以把这些机器规组，这样就可以将不用调用者对于同一个服务的调用进行隔离了。
服务自身部署方式

将服务框架作为应用的一个依赖包，与应用一起打包，这样就是存在问题，如果要升级服务，就要更新应用本身，并且服务框架没办法接管classloader。
服务框架作为容器的一部分

jar包冲突处理

通过Classloader, 使用用户自定义的ClassLoader，将服务框架自身用到的类和应用用到的类都控制在User-Defined Class Loader级别，这样就实现了相互的隔离。
Web容器对多个应用的处理，以及OSGi对于不同Bundle的处理都采用了类似的方式。

运行时版本统一的情况

需要服务框架比应用优先启动，并且把一些需要统一的jar包放到User-Defined Class Loader所公用的祖先ClassLoader中。

通信方式

透明代理
通过服务注册查找中心进行直连

服务的拆分

要拆分的服务是需要为多方提供公共服务的，对于那些比较专用的实现，如果它们是独立部署在远程机器上的，就不需要拿出来做一个服务了，增加系统的复杂度。

服务的粒度

这是很难量化的方面，需要根据业务的实际情况来划分。

优雅与实用的平衡

在做服务化的同时，还需要考虑到实用性，服务化并不是标准，目的就是一个，提高系统的性能。服务化虽然能够是系统的架构更加优雅清晰，但是如果损失了性能就本末倒置了。

分布式环境中的请求合并

Future方式
分布式锁服务
路由策略

在多机环境中，需要由独立于服务调用者、服务提供者之外的节点来完成相关的工作，也就是需要分布式锁服务来控制。需要考虑其性能。

另外一个思路： 根据一定的规则把同样的请求发送到同一个服务提供者上，然后在服务提供者的机器上做单机控制，这样通过路由策略的选择，可以不用引入分布式锁服务，减少了复杂性。

此外，对于比较消耗资源的操作，不论是使用分布式锁服务，还是采用路由方式把请求送到特定机器，在服务调用者上都可以进行单机多线程的控制。

具体采用何种方式，需要根据具体场景来决定，而且需要数据的支持来做最后的决定。