系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？
1. 问题描述
系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？
问题结论
架构都是为业务而服务的，我们在选择具体哪个架构的时候肯定是基于业务进行选型。微服务适用于大型互联网公司，需求迭代比较快。如果业务相对而言比较简单，单体应用不失为一个很好的选择。
2. 微服务简述
2.1 微服务的理解
微服务就是按照业务划分，将一组特定的业务划分成一个服务（比如：支付系统，只是服务库存做操作，不涉及到其他任何业务），每个服务都有自己独立的数据库，独立部署，服务直接通过rest api（或rpc api）进行通讯。每一个独立运行的服务组成整个系统。
微服务的架构风格就是一个大型软件系统由一个或多个微服务组成。每个微服务仅负责一件业务任务，系统中各个微服务可被独立部署，更快地交付并推出市场，各个微服务之间是松耦合的。
比如我们所看到的各种电商App，其对接的服务端很可能是成百上千个微服务，即使团队内部，也很难说清楚到底有多少个服务，也许一个页面就涉及到4~5个微服务，其各自均有独立的数据库与之对应。
2.2 微服务的优点
相比起集成式大型应用。微服务主要优点在于：
每个服务足够内聚，足够小，代码容易理解、开发效率提高。
服务之间可以独立部署，微服务架构让持续部署成为可能。
每个服务可以各自进行负载均衡扩展和数据库扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上。
容易扩大开发团队，可以针对每个服务（service）组建开发团队。
提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪。
统不会被长期限制在某个技术栈上，在合理的通信机制下，每个微服务可以独立使用自己的技术栈。
2.3 微服务的缺点
运维要求比较高：之前就一个war包，现在一个系统中会有很多的服务，每个服务都对应一个war包，维护起来就会变得很麻烦。
技术复杂性提高：微服务就会带来一系列的问题，事务问题，Session一致性问题，锁问题，服务治理问题、多环境实例管理问题、微服务架构拆分粒度和时机的把我问题等。
3. 小结
不必强求微服务“全家桶”套餐，理解微服务的优势，也要警惕微服务造成的问题。一般来讲，能单应用就用单应用，业务量大可以考虑做分布式集群。更大规模的场景，单应用已经无法支撑业务，考虑微服务化。为了微服务而微服务完全没有必要，在提出微服务概念以前，一个大系统本身分成很多小系统，这和现在的微服务并没有本质的区别。而微服务本质是应对复杂的系统架构，n个小团队维护大的系统规模，在遗留系统中做架构演进，各个微服务独立部署又紧密集成，共同支撑业务系统提供服务。
作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。