2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，然后微服务就开始火遍大江南北，很多技术团队和公司开始使用微服务架构，然而，谁用谁痛谁知道，“微服务”绝对不是银弹。使用“微服务”架构一定要慎重！

什么是“微服务”？

“微服务”并没有严格意义上的定义和规范，借用一段维基百科上的描述：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。微服务架构运用于软件架构风格的其中一项概念是甘露运算 (Dew Computing)，意指由许多的小露水 (代表微服务的功能元件) 汇集而成的运算能力。

“微服务”架构的优点

哪位看官问，既然“微服务”架构能火遍大江南北，那它一定有它的优势吧？是的，任何事物能够存在甚至大热，都不可能是无缘无故的，必有其道理所在。“微服务”架构自然也不例外！其优点如下：

• 独立性，每个微服务都可以部署在独立的物理机、虚拟机或者Docker上，使其原生具备分布式的架构设计；

• 可扩展性，基于其独立性，可以容易的根据业务或技术线对微服务架构进行水平或垂直扩展；

• 可升级性与易维护性，依然基于其独立性，每个微服务都可独立进行升级与维护

• 任意编程语言，每一个微服务都可以按照开发团队自己熟悉的编程语言进行开发，然后按照REST协议或者RPC协议制定API来提供服务

一些团队看到“微服务”架构的优点就像是找到了救命稻草一般，立即开始实施。结果，他们遇到的是，系统间、服务间的高耦合，导致团队间协作大打折扣；测试进行集成测试时，需要遍历整条业务线的多个微服务系统，导致测试用例指数攀升，而测试效果却不太理想。有一定经验的看官可能回想，这群人一定是在“微服务”架构划分的时候做的不够好，才会耦合度这么高。可这么多公司前仆后继的掉进这个坑里，你就不得不想这其中的必然性了。让我们看看对于“微服务”架构的一些误区。

“微服务”架构的误区

• “微服务”架构能够让系统结构看起来更清晰和简洁

一个简单的事实，就算是单一系统，只要架构设计合理并严格执行代码的架构审核，结构清晰和简洁一样很容易做到。一些团队长期受到现有代码架构混乱的蹂躏，拿起“微服务”就来用，其实简单的代码迭代重构在很多情况下是更加可控的选择。

• “微服务”架构很容易实现

首先，“微服务”架构的解耦就够你受的；其次，不可避免的会在一次请求中涉及多个服务，而多个服务有可能相互依赖，此时分布在不同微服务的数据很可能是事务性的，这种分布式的事务处理，搞不好就会出大事。

• “微服务”更快

不可否认，论到单个微服务的优化，我们可以从减少单个微服务处理的业务类型，使其更加专一等手段来提升其执行效率，但是源自微服务的分布式架构，其网络I/O的代价必须考虑在内，

这使得原来在单一系统中程序内部的信息交换被搬到了网络层，一个不小心，程序效率降低妥妥的。

• 对程序员更简单

由于微服务往往更专注于一个单一的功能，因此开发人员在处理功能内部问题时，的确会更加简单一些。但微服务的目的是在集成系统中承担部分服务，不可避免的要与核心系统或系统的其它部分进行协作交互，一旦出现跨越多个微服务的问题，不但需要开发人员对涉及的系统有所了解，涉及的多个团队还需要进行同步协助来处理Bug，而可能遇到的一种情况是，人们对于这种Bug缺乏责任感，经常会想方设法的将bug推给其他团队，沟通成本严重影响开发效率。

另外，对于测试人员，一点小的改动就有可能需要多个服务的继承测试，无论从测试用例的复杂度还是测试环境的搭建，都是一件不简单的事情。

何时使用“微服务”架构

• 当你的系统已经具备很大的规模，集成了大量的服务，可以考虑部分使用“微服务”，千万不要在项目初期就使用微服务，此时整个系统还很小，随着系统和业务的不断成长，系统架构会经历大量的变更，如果在初期就使用微服务，很容易造成微服务间的强耦合。
• 当你对你的系统具备非常深刻的认识，并且能够很轻易的划分出各个功能、服务的边界，此时可以尝试考虑“微服务”架构
• “微服务”架构应该以业务划分为主，业务与业务之间的耦合度可以轻易的看出，以业务进行划分，系统的耦合度比较可控
• 最后，只有你能真正列出系统迁移到微服务架构的利与弊，并做好了应对之策时，才可以着手实施

如果你有任何问题或建议，可以扫描下方二维码或者为微信搜索[phpjiagoushier]，关注我的微信公众号[PHP架构师]，参与互动交流。

慎用“微服务”架构