读分布式服务框架原理与实践读后感

         从来没有写过一篇读后感，利用每天早上早到办公室的半个小时时间，零零散散的将《分布式服务框架--原理与实践》给读完了。也许是我自己的能力有限，源码部分没有怎么关注，但是里面的大概知识点，我结合公司现有的框架，总感觉公司里面的东西能够往书里面讲到的东西上面靠，所以读起来比较happy。也会经常问一些公司大牛，他们认为比较low的问题。

       其实，代码和天下一样，合久必分。当你的系统足够大，很难维护的时候，这个时候就需要将代码进行服务化了。还记得我之前刚进公司的时候，我们项目在上线部署的时候，大约需要半个小时发布。里面涉及到的代码，牵一发而动全身。需要测试进行全流程回归测试。而分布式服务化的好处是将职责分开出去，按照功能模块，各个模块单独部署。单独的团队进行维护。这就要对各个服务的版本进行有效的控制，而且版本需要向前兼容。

     在读书的过程中，我也产生过疑问，如果将系统服务化，以前在项目中一起的代码之间的调用，效率会很高。不会依赖于外部网络，不会有那种流量啊，参数传递啊之间的那种交互问题。但是这样的话，会存在一种场景，好几十号甚至几百号的人，共同维护一套代码，只要有一个团队的人上线有问题，则系统就会发布失败。其实，如果公司的运维跟得上，后台够硬，这些问题都能够解决。-如果将系统服务化部署，这样的话，就会减少各个模块之间的依赖，各个系统模块的上线发布是独立的，对别的系统是不可知的，假如一些非核心的业务单独部署了，且宕机了，那么系统还能正常运行，对核心业务没有影响。

    之前项目中也会用到服务降级技术，一直听说，但是不知道为啥要使用它，现在明白了，服务降级包含容错降级和屏蔽降级，可以将流量集中到核心业务功能上面。

   写的有点乱，有点杂。个人小结，不喜勿喷。谢谢！