慎用“微服务”架构
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了慎用“微服务”架构相关的知识,希望对你有一定的参考价值。
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架构师],参与互动交流。
以上是关于慎用“微服务”架构的主要内容,如果未能解决你的问题,请参考以下文章