到底是否应该使用“微服务架构”? - LinkinStar - 博客园

标签: | 发表时间:2019-11-24 17:38 | 作者:
出处:https://www.cnblogs.com

前言

经过当前服务端的洗礼之后,市场出现了一波微服务的热潮。然后就出现了很大的一个问题,无论什么项目,很多人想都不想,都直接开始说我们使用微服务架构来完成吧,用这个、这个组件很简单就能实现。。。而且,现在市场上很多学习教程都直接教授微服务的架构使用。很多学习的人看到这样的趋势就会随大流,就导致了当前的问题,炒作这样概念的人很多,很少人知其所以然。

经过一段时间的整理,梳理出了下面几个点,可供参考。

希望经过这些简短的参考能帮助你认识,技术的所以然。

 

什么是“微服务架构”

官方:一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可以独立部署。依赖一个最小型的集中式管理。

总结为几点:

1、独立运行

2、独立部署

3、独立开发

4、轻量级通信

5、集中管理

这样说还是有点抽象,举个实际的例子来说,比如购物:我们可以拆分为,用户微服务,订单微服务,商品微服务…..

每个服务都有以上特点,之间独立,又可以通信,依赖一些管理的东西去管理他们。

中心思想:把大系统拆分成小型系统,把大事化小,以降低系统的复杂性

 

“微服务架构”的优点和缺点

如果只是说一个东西的优点是没用的,只有对比来看,所以我们对比单体应用来说明其优点。

1、部署:

单体应用部署肯定简单,一个包扔进去,容器启动就可以了。

微服务应用部署会负责,服务越多部署越麻烦,而且有些依赖与一些中间件,所以运维和部署的压力变大是肯定的。(这里并不是说一定的,已经有一些运维部署的软件方便了微服务的部署)

2、开发和维护:

单体应用如果要进行开发,代码即使分离的再好,那么还是在一起,所以会显得臃肿,维护起来不方便,如果需要改动一个点,整个服务必须全部重新启动。

微服务开发因为本身分离,所以显得清晰,维护起来方便,一个地方的服务出现问题,只需要改动对应服务并重启对应服务即可。

3、扩展:

单体应用扩展可想而知,受限并且压力很大,到最后很多人会发现,加入或者扩展功能时宁可新开发一个也不愿意去依赖原来的代码就怕改了原来的代码之前的代码出现问题。

微服务扩展能力较好,新加入一个功能不会对原来的系统造成影响。而且如果一个大的功能被禁用,直接停止对应服务即可。

4、通信:

对于单体应用来说,自己本身都是内部服务调用不存在通信问题,对于外部库来说,通信方式取决于外部库的依赖。

微服务之间的通信就需要依赖比较靠谱的通信系统了,因为难免服务与服务之间会有依赖,那么通信方式的选择就尤为重要了。

 

到底是否应该使用“微服务架构”?

最后我们再来看看我们一开始的问题,是不是就能总结出以下几个点了。然后我结合一些书本和经验做下面一个总结,希望对你有帮助。

1、系统大小

这是我们首要的考虑目标,如果一个系统很小,比如一个官网,那你说做微服务就是扯淡了。那么如何确定一个系统的大小呢?可以参考一下下面这个标准。

如果你的项目能分成三个或三个以上的耦合度很低的项目,那么就算大。

如果你的项目数据库表超过30张,且单表数据轻松百万,那么就算大。

如果你的项目之后会进行扩展,并且扩展之后会达到上面的如果,那么也算大。

虽然只是经验上的估计参考,但是也从侧面体现出,如果项目不大,那么真的就没必要。

 

2、技术能力

微服务依赖的能力有以下几点

拆分服务的能力

处理分布式问题(网络请求,分布式事务等)的能力

强大的运维能力

如果一个系统决定使用微服务架构,那么前期的拆分就显得非常重要,有经验的拆分可以让服务之间的耦合对降到最低,并且相应的业务没有问题。相应的,如果没有处理分布式问题的能力也是不行的,最后才是项目部署运维的能力。

 

3、团队规模和时间

如果你的团队规模不超过10人,那么除非你们能力都非常牛,而且都能独当一面,那么当我没说,理论上不建议。

在开发周期时间不允许的情况下不要执意去切换,从单体切换到微服务,因为两者区别不仅仅是在服务上,包括通信等等方面耗时都不短,测试上面就需要更加多的时间去测试。而且微服务的开发效率上面是一开始慢,到项目大了之后开发效率才慢慢的体现出来。

微服务毕竟存在通信,而且服务器想对多,项目稳定性上肯定要打折扣。你的团队需要提前了解到这样的问题,并做好遇到问题的准备和处理,这也是需要时间的。

团队之间的沟通,有通信必然有交流,不然别人怎么知道你的服务是怎么样的。那么接口文档编写的时间和对接接口的时间,调试的时间,剩下我就不多说了,你应该懂了。

 

总结

一个技术或者一个架构不是万能的,每个技术都有适用的场景,我们所要做的不是一味的追求最新,而是明白它的使用场景或者优点缺点,从而来考虑是否使用。

这里上面也只是抛砖引玉,所有的细节肯定不是一篇文章或者一本书能说完的,只要你去考虑了,借鉴一些别人的经验去发现可能存在的问题,那么即使最后出现问题也可以被解决。

 

参考文档:

《SpringCloud与Docker微服务架构实战》

http://www.infoq.com/cn/minibooks/microservice--from-zero

 

相关 [微服务 架构 linkinstar] 推荐:

到底是否应该使用“微服务架构”? - LinkinStar - 博客园

- -
经过当前服务端的洗礼之后,市场出现了一波微服务的热潮. 然后就出现了很大的一个问题,无论什么项目,很多人想都不想,都直接开始说我们使用微服务架构来完成吧,用这个、这个组件很简单就能实现. 而且,现在市场上很多学习教程都直接教授微服务的架构使用. 很多学习的人看到这样的趋势就会随大流,就导致了当前的问题,炒作这样概念的人很多,很少人知其所以然.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务实战(一):微服务架构的优势与不足 - DockOne.io

- -
【编者的话】本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战. 正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足. 如果你想和我或者更多微服务专家交流,可以加我微信liyingjiese,备注『加群』. 群里每周都有全球各大公司的最佳微服务实践以及行业最新动态.