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

前言

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

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

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

什么是“微服务架构”

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

总结为几点:

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

原文地址:https://www.cnblogs.com/linkstar/p/9011643.html

时间: 2024-11-06 07:49:06

到底是否应该使用“微服务架构”?的相关文章

阿里巴巴微服务架构到底有多牛逼?

微服务架构专题 围绕微服务的通用模式,讲解Spring Cloud的常见用法及原理.让微服务的开发更加方便.快捷,让微服务应用更加稳定.可用. 理论结合实战,透彻理解分布式架构及其解决方案. 面向人群 1.工作1-5年需要突破瓶颈 2.传统行业转型进入互联网行业的人群 在技术深度和技术广度上得到飞跃的提升.成为互联网行业所需要的IT型人才 微框架 1.与微服务之间的关系 2. 热部署实战 3.核心组件Starter.Actuator.AutoConfiguration.Cli 4.集成Mybat

微服务架构

互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小公司在开始技术选型时感觉某个框架费时费力就不会选择,而小公司发展到大公司的过程,一般也伴随着系统不断优

【读书笔记】微服务架构与实践

一:概述 微服务实在互联网大浪潮下顺势而起的 微服务降低了单个问题的复杂性,但是提高了整体上运维和部署的难度 二:基础篇 提出以下4个问题 神马是微服务 微服务到底怎么发展起来的? 微服务的优势在哪儿里?为什么现在大家都在谈微服务 微服务有不什么不足,或者对使用微服务说有什么挑战? 作为从业者的我们到底要怎么看待微服务,并且如何在实际的工作项目中使用它? 分别针对上面的四个问题,做出解答 什么是微服务? 微服务更像是一种架构模式,不是某种具体的技术.提倡将单一的应用划分为一组小的服务,服务之间相

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

Re:从0开始的微服务架构:(一)重识微服务架构--转

原文地址:http://www.infoq.com/cn/articles/micro-service-architecture-from-zero?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage 导语 虽然已经红了很久,但是“微服务架构”正变得越来越重要,也将继续火下去. 各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

(转)微服务架构 互联网保险O2O平台微服务架构设计

http://www.cnblogs.com/Leo_wl/p/5049722.html 微服务架构 互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小

互联网转型需要微服务架构

微服务出现的时间不短了,但是为什么现在才这么重视它?互联网转型要转型什么? 第一,以职能为中心转向以用户为中心.我们过去的信息化更多的是依照部门职能,有什么样的工作内容,有什么样的流程,然后去做系统.下一步的信息化更多的是以用户为中心.为什么是以用户为中心?我们要看用户到底需要什么,在什么样的场景下需要什么样的信息支持.过去我们只在内部做很多系统,其实用户体验也非常的不好,用户需要的东西也没有. 第二,从流程驱动转向数据驱动.过去都是看业务流程是什么样的,流程中间需要什么样的数据来支持.随着移动

微服务架构与实践-王磊

(原文地址:http://www.infoq.com/cn/articles/microservice-and-continuous-delivery) 摘选书中节选-微服务与持续交付 十年以前,软件在一年之内的交付次数屈指可数. 过去的十年间,交付的过程一直被不断地优化和改进.从早期的RUP模型.敏捷.XP.Scrum,再到近几年的精益创业.DevOps,都力求能更有效地降低交付过程所耗费的成本并提高效率,从而尽早实现软件的价值. 持续交付是一种软件开发策略,用于优化软件交付的流程,以尽快得到