试读《分布式服务框架原理与实践》

        随着移动互联网产业的兴起和发酵，后端技术也悄然发生着巨大的改变，以往的企业级应用不同的是面对需求变化逐渐变快，访问压力指数增长，安全效率及维护性要求达到新的高度，如何能过应对这些问题并迅速而低风险地发布迭代已经是当务之急。变繁为简、提升系统的敏捷度是不错的应对之策，由此“微服务“的概念就迅速蹿红。

 

        从字面上看”微服务“分为”服务“和”微“，服务化的概念由来已久，而”微“即将服务归类并最小化，相信”尾大不掉“这个词都听过，那么道理是差不多的。

 

        作者在序中阐述了自己的一个项目微服务化的前因和后果，其中他们所面对的问题相信很多读者也都面对过或者正在面对抑或马上也要面对：1）代码重复度高，2）需求变更困难，3）部署效率低，4）学习成本高，5）缺乏统一的RPC框架。

 

        随即引入服务后RPC使用会引入新的需求：

1. 依赖管理
2. 透明路由
3. 服务治理
4. 其他

    本书即在阐述以上问题的解决理论及实践。从目录章节看作者足足写了21章，可谓非常详尽，那么是不是浅尝辄止呢？我没有读过所以未曾可知（PS：作者的那边netty的书还是写的不错的，所以本书质量应该也是不差的），希望有幸能获得来拜读下。

 

第8章 服务调用--试读

8.1几个误区

        NIO就是异步服务。同步调用和异步调用跟IO并没关系，就是说IO同步或是异步都能做调用的同步和异步。

        调用都是同步的。并不确切，Future-Listener在不阻塞业务的同时实现了同步等待的效果。

        异步服务调用性能更高。

 

8.2调用方式

        1. 同步调用
        2. 异步调用
            1). Future get方式，多个服务调用的总时间=T1+T2+....Tn

            2). Future Listener方式，多个服务调用总时间=Max(T1, T2,...Tn)

        3. 并行调用

            1). Parallel Gateway（并行网关）推荐使用

            2). Java8 Fork/Join （不推荐）会导致线程膨胀不可控

        4. 泛化调用

            泛化引用：指客户端没用接口及数据模型，参数都是基本类型及Map。

            泛化实现：服务端没用接口及数据模型

 

8.3 最佳实践

•     降低e2e延时：梳理调用流程，通过并行调用提升调用效率
•     可靠行：调用链的关键服务不可靠，一旦出现故障会导致大量线程资源被挂住，可以考虑异步服务防止故障扩散
•     传统RPC调用：对延时要求不高的，考虑同步调用。

         本章介绍了几种常用的调用方式及使用场景，并解释了其中的一些误解。

       

        在以往的经验中，实现并行调用异步调用都是业务开发人员自行编码完成，虽然也能实现，但限于技术水平的高低实现好坏差异比较大，而且代码也严重重复，业务代码中掺杂这类的代码从维护角度来讲不太优雅，所以如果调用框架能过封装掉这些，那么从使用和维护上讲都是很棒的。