大型网站系统与Java中间件—读书笔记4（服务框架）

一 网站功能持续丰富后的困境和应对

      困境：访问压力不断增大  开发人员增多 应用复杂臃肿 代码冗余 数据库压力增大

      应对：1 把应用拆小 

                    问题： 数据库压力依旧在 存在重复代码

                    如商品管理和交易管理等功能中，都会调用与用户相关功能

                 2 服务化方案  在应用和底层间增加服务层

                    影响：系统架构更加立体  更好维护 提高稳定性

                               系统内部的依赖变得错综复杂

---

二 服务框架的设计与实现

     1 应用从集中走向分布式所遇问题

        为服务层做一个RPC功能，为服务使用者提供相关客户端 （远程调用） 

        服务框架需要解决问题：接口调用/寻址路由/编码/通信 

     2 通过示例看服务框架原型 

        计算器例子   抽离接口

        客户端：       获取可用服务列表地址

                             确定要调用服务的目标机器

                             建立连接

                             请求序列化

                             发送请求

                             接受结果

        服务端：      启动监听

                            接受请求

                            定位具体服务

                            本地调用

                            结果返回

     3 服务调用段的设计与实现

         确定服务框架使用方式：如何在客户端引入和使用服务框架

         Spring框架中引入服务框架 属性： interfacename/version/group

         运行时服务框架与应用和容器的关系：作为Jar包/作为容器的一部分 

         调用者与提供者的通信方式：中间代理服务器/服务注册查找中心（服务与调用直连）

         引入基于接口 方法 参数的路由

         多机房场景

         调用段的流控处理

         序列化与反序列化处理

         网络通信：BIO NIO AIO   异步服务调用方式

     4 服务提供段的设计与实现

        如何暴露远程服务：服务端工作内容 对本地服务的注册管理

                                                                  根据请求定位服务并执行

       工作流程：接受请求 反序列化

                         定位服务

                         处理结果

                         序列化

                         网络通信      

     5 服务升级

        两种情况：接口不变，代码本身进行完善 

                          接口改变：在接口中增加方法 让新方法的调用者使用新方法

                                            修改方法的参数列表（通过版本号来解决）

---

三 优化 

     1 服务的拆分

     2 服务的粒度

     3 优雅和实用的平衡   读数据较多时，让调用者直接读缓存（架设在本地）

     4 请求合并