传统单体式服务的缺点:
1.开发进度越往后,开发的难度就越大。
2.技术债务越来越多,早期开发的系统经历多次技术与人员迭代后,会不可避免地积攒隐藏bug
3.系统耦合性大,导致拓展性很低(拓展性分为垂直拓展与横向拓展,可以理解为垂直拓展是增加货车的容量(系统的载荷量),而横向拓展就是增加货车的数量)
4.技术选型困难,语言,框架的选择会直接决定系统成型后的质量。对于单体式服务架构来说,开始选择完技术架构后就无法在后期进行更改,无法应对多变的需求
微服务的优点:
1.耦合度很小,每个功能可以直接对应一个进程,进程与进程之间通过rpc协议交互。
2.几乎不存在技术选型困难:以语言和框架为例,在微服务架构中,每一个服务都可以使用不同的语言开发(这也是因为存在rpc协议,使得不同语言之间可以无障碍交流),大大降低了技术选型的困难。例如在AI有关的模块可以使用python开发,大数据模块使用java。
3.轻量级交流:即上述不同开发语言之间可以实现交互,通过rpc协议
4.开发的人力资源降低,著名的有2披萨团队
微服务的缺点:当然,微服务并不是全无缺点。首先是微服务的运维成本很高,因为进程的数量多,所以在开启时必须要开启多个服务。同时管理上也极为困难。测试上,微服务需要单个单个进行测试,最后还要进行集成测试,比起单体架构来说更加麻烦。开发成本也相对更高
什么是微服务:
微服务可以看成是分布式的具体实现,在传统的单体式服务中,所有的客户端必须访问中心服务器,中心服务器通过处理,再将数据返回给对应的客户端,这里最明显的一个点就是所有这些处理都在一个服务(进程)内完成,即使现代的框架有使用模块化来解耦,但耦合度依旧很大。微服务则是将所有的功能模块都各自分配一个服务,服务与服务间需要交互时就通过rpc协议交互。
例如淘宝,在曾经的一次双十一,由于载荷量太大而导致订单提交非常缓慢,交货地址的修改功能直接崩溃,但当时并没有使得服务器直接挂起。这就是微服务的解耦度很高,同时也不难看出微服务具有很强的防攻击性。
rpc协议:
rpc协议也称为远程过程调用协议(IPC,进程间通信,可以相互记忆),属于应用层协议,底层通过tcp协议实现。它使得我们可以像调用本地函数一样去调用远端的函数。