慎用“微服务”架构

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架构]，参与互动交流。