微服务学习笔记

传统单体式服务的缺点：

    1.开发进度越往后，开发的难度就越大。

    2.技术债务越来越多，早期开发的系统经历多次技术与人员迭代后，会不可避免地积攒隐藏bug

    3.系统耦合性大，导致拓展性很低（拓展性分为垂直拓展与横向拓展，可以理解为垂直拓展是增加货车的容量（系统的载荷量），而横向拓展就是增加货车的数量）

    4.技术选型困难，语言，框架的选择会直接决定系统成型后的质量。对于单体式服务架构来说，开始选择完技术架构后就无法在后期进行更改，无法应对多变的需求

微服务的优点：

    1.耦合度很小，每个功能可以直接对应一个进程，进程与进程之间通过rpc协议交互。

    2.几乎不存在技术选型困难：以语言和框架为例，在微服务架构中，每一个服务都可以使用不同的语言开发（这也是因为存在rpc协议，使得不同语言之间可以无障碍交流），大大降低了技术选型的困难。例如在AI有关的模块可以使用python开发，大数据模块使用java。

    3.轻量级交流：即上述不同开发语言之间可以实现交互，通过rpc协议

    4.开发的人力资源降低，著名的有2披萨团队

微服务的缺点：当然，微服务并不是全无缺点。首先是微服务的运维成本很高，因为进程的数量多，所以在开启时必须要开启多个服务。同时管理上也极为困难。测试上，微服务需要单个单个进行测试，最后还要进行集成测试，比起单体架构来说更加麻烦。开发成本也相对更高

什么是微服务：

    微服务可以看成是分布式的具体实现，在传统的单体式服务中，所有的客户端必须访问中心服务器，中心服务器通过处理，再将数据返回给对应的客户端，这里最明显的一个点就是所有这些处理都在一个服务（进程）内完成，即使现代的框架有使用模块化来解耦，但耦合度依旧很大。微服务则是将所有的功能模块都各自分配一个服务，服务与服务间需要交互时就通过rpc协议交互。

     例如淘宝，在曾经的一次双十一，由于载荷量太大而导致订单提交非常缓慢，交货地址的修改功能直接崩溃，但当时并没有使得服务器直接挂起。这就是微服务的解耦度很高，同时也不难看出微服务具有很强的防攻击性。

rpc协议：

rpc协议也称为远程过程调用协议（IPC，进程间通信，可以相互记忆），属于应用层协议，底层通过tcp协议实现。它使得我们可以像调用本地函数一样去调用远端的函数。