随着系统越来越庞大,参与人员越来越多,这时候人员的交流成本,发布成本,变动成本越来越高。这时候我们开始选择更改组织架构,项目架构来改变这种系统越来越庞大所带来的副作用。
康威定律,一个项目的架构等同于其组织架构。
说白一点微服务其实就是一种模块化形式,提供标准接口,和当年硬件标准化一样,其内部结构不一致,但是其提供的接口是一致的。即使不同厂家生产的我们也可以即插即用,而且可以将我们的优势发挥出来,只关注我们的业务模块即可,不必关注其他服务或者硬件的好坏,只要关注自己领域的业务,并且提供标准接口即可
在说明一件事的好处之前,我们要预计其所带来的坏处。微服务带来的坏处有哪些:
1.最终一致性
2.测试复杂性
3.运维复杂性
4.硬件成本
我觉的最重要的一点就是最终一致性(事务),目前业内没有一个大家都认可的全局事务处理框架,阿里目前出的fescar,seata还是项目建设初期,还有待完善。
测试复杂,一个测试用例需要多个服务应用进行配合,不是之前测一个流程即可。
运维复杂,需要多个服务进行配合才能把系统启动成功
硬件问题,目前微服务之间都是通过网络互相调用,有通过http,有通过rpc来进行互相调用,不管使用何种方式这时候就需要我们的网络性能很强大,如果微服务之间的网络如果达不到万兆带宽的时候,就开始微服务,使用网关将会是非常痛苦的一件事情