微服务架构

优点

容易掌控

小的程序容易掌控。如果只有少数几个功能的服务，即使是对初级的程序员，也不难迅速掌握程序全貌。无论是新增功能、修改Bug、重构，都很方便。反之，一个巨大的程序怪兽，即使是非常资深的程序员，恐怕也很头痛。

服务性能高

对于有垃圾回收机制的语言，如Java。过大的部署会带来大量的垃圾需要回收，而我们知道垃圾回收的时候系统是暂停的，这对用户体验会带来一定影响。而小的部署，垃圾回收时间短，对用户体验影响小。

服务出问题影响小

微服务下，一个服务出问题，一般就影响这个服务及其关联服务。对单块服务来说，一旦出问题，很多就会出现整个服务当机，所有服务不可用。

单元测试容易

一个大型应用，可能包括数千个单元测试案例，同时由于各个模块之间不可避免的耦合，导致单元测试编写困难。一个小的服务，通过外部接口和其他服务耦合，很清楚自己做什么不做什么，单元测试就比较容易编写，代码质量也会提高。

技术栈更灵活

在单块系统中，一般语言肯定是一个，存储技术也不会太多。大家知道不同技术，特别是存储技术，适合于不同的场景。如文档用MongoDB，关系型数据用RMDB，文件用分布式文件系统等。对于单块系统，在一个系统中整合多种技术，进一步提高了系统的复杂性。而对微服务，每个服务都可以根据自己需要决定用何种适合的技术（当然太多的话会对公司招聘等带来压力）。对于新技术的尝试，由于只有一个小服务，压力也会很低。

单一职责原则

在单块系统中，由于所有业务都在一个代码库上，虽然模块上有职责的划分，但时间久了，很难避免有些业务就违反单一职责原则了。代码相互耦合在一起，改动困难。对微服务来说，不同模块都不在一个代码库上，相互之间通过远程调用接口进行解耦，你也直接访问不了别人的数据，被迫实施单一职责。

缺点

部署问题

分为微服务后，必然拆分成更多的部署，这对服务器的管理和运维来说是很大挑战。因此微服务必然依赖自动化来解决，自动化部署、测试。这方面也有很多成熟的工具，如puppet，用python+fabric也不错。如果用了微服务而不用自动化，那么部署给你带来的可能是噩梦。

事务问题

跨服务的事务是个噩梦，两段提交性能又太低。这种情况下可能更多要改为事后一致性，保证最终数据的一致性。比如在用户服务上，当注册一个用户的时候，要给他发优惠券，优惠券可能是另外一个服务。单块服务程序可能会把这两块写一起，这就造成了代码易变。在为服务架构上为了保证数据一致性，可以采用MQ的方式通知其他模块。在主服务完成操作后，同时在事务中插入一个事件，随后由程序把事件发布到消息队列上。订阅了这个消息的模块，就会根据这个消息来进行自己的操作，比如发放优惠券。

报表

对企业应用来说，报表是很常见的。对单数据库来说，拉报表不过是拼装一个大的SQL而已。对微服务来说，每个服务数据库可能不在一起，而且可能采用不同的数据库！那么报表就是个巨大的挑战，比以前实现要复杂很多。比如你可能需要定期导出数据，并由程序处理成报表需要的格式，这方面要做出一些牺牲。

性能问题

上面刚说过有点是性能高，这里又说性能。这里说的性能是指由于远程调用的问题，会让用户使用的性能可能会下降。由于用户一次访问可能会涉及到多个服务之间的远程调用，每次都会有一定网络延迟。不过一般这些延迟都是在服务间进行，相对于数据存取所需要的时间来说，应该是可以忍受的。