优点
容易掌控
小的程序容易掌控。如果只有少数几个功能的服务,即使是对初级的程序员,也不难迅速掌握程序全貌。无论是新增功能、修改Bug、重构,都很方便。反之,一个巨大的程序怪兽,即使是非常资深的程序员,恐怕也很头痛。
服务性能高
对于有垃圾回收机制的语言,如Java。过大的部署会带来大量的垃圾需要回收,而我们知道垃圾回收的时候系统是暂停的,这对用户体验会带来一定影响。而小的部署,垃圾回收时间短,对用户体验影响小。
服务出问题影响小
微服务下,一个服务出问题,一般就影响这个服务及其关联服务。对单块服务来说,一旦出问题,很多就会出现整个服务当机,所有服务不可用。
单元测试容易
一个大型应用,可能包括数千个单元测试案例,同时由于各个模块之间不可避免的耦合,导致单元测试编写困难。一个小的服务,通过外部接口和其他服务耦合,很清楚自己做什么不做什么,单元测试就比较容易编写,代码质量也会提高。
技术栈更灵活
在单块系统中,一般语言肯定是一个,存储技术也不会太多。大家知道不同技术,特别是存储技术,适合于不同的场景。如文档用MongoDB,关系型数据用RMDB,文件用分布式文件系统等。对于单块系统,在一个系统中整合多种技术,进一步提高了系统的复杂性。而对微服务,每个服务都可以根据自己需要决定用何种适合的技术(当然太多的话会对公司招聘等带来压力)。对于新技术的尝试,由于只有一个小服务,压力也会很低。
单一职责原则
在单块系统中,由于所有业务都在一个代码库上,虽然模块上有职责的划分,但时间久了,很难避免有些业务就违反单一职责原则了。代码相互耦合在一起,改动困难。对微服务来说,不同模块都不在一个代码库上,相互之间通过远程调用接口进行解耦,你也直接访问不了别人的数据,被迫实施单一职责。
缺点
部署问题
分为微服务后,必然拆分成更多的部署,这对服务器的管理和运维来说是很大挑战。因此微服务必然依赖自动化来解决,自动化部署、测试。这方面也有很多成熟的工具,如puppet,用python+fabric也不错。如果用了微服务而不用自动化,那么部署给你带来的可能是噩梦。
事务问题
跨服务的事务是个噩梦,两段提交性能又太低。这种情况下可能更多要改为事后一致性,保证最终数据的一致性。比如在用户服务上,当注册一个用户的时候,要给他发优惠券,优惠券可能是另外一个服务。单块服务程序可能会把这两块写一起,这就造成了代码易变。在为服务架构上为了保证数据一致性,可以采用MQ的方式通知其他模块。在主服务完成操作后,同时在事务中插入一个事件,随后由程序把事件发布到消息队列上。订阅了这个消息的模块,就会根据这个消息来进行自己的操作,比如发放优惠券。
报表
对企业应用来说,报表是很常见的。对单数据库来说,拉报表不过是拼装一个大的SQL而已。对微服务来说,每个服务数据库可能不在一起,而且可能采用不同的数据库!那么报表就是个巨大的挑战,比以前实现要复杂很多。比如你可能需要定期导出数据,并由程序处理成报表需要的格式,这方面要做出一些牺牲。
性能问题
上面刚说过有点是性能高,这里又说性能。这里说的性能是指由于远程调用的问题,会让用户使用的性能可能会下降。由于用户一次访问可能会涉及到多个服务之间的远程调用,每次都会有一定网络延迟。不过一般这些延迟都是在服务间进行,相对于数据存取所需要的时间来说,应该是可以忍受的。