企业应谨慎对待微服务架构

标签: IT咨询 | 发表时间:2016-11-05 11:04 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
对于微服务架构我在前面很多文章里面已经都谈到过了。

微服务架构本质是 单个业务系统彻底的组件化(前端,逻辑层,数据库)解耦,同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的,实现微服务架构后,你会看到没有传统业务系统的概念了,有的只是微服务模块或小应用。

微服务架构最近又炒的相当活,很多人会说SOA过时了,ESB过时了,甚至还有人用微服务架构去彻底的否定SOA和ESB,这些都是相当危险的信号。在我12,13年写企业私有云PaaS平台的一系列文章的时候,已经提出了业务能力组件化,组件服务化的微服务架构思想,但是实际应用实施效果并不太理想。

一个企业所涉及到的IT开发和架构能力以及企业本身的IT治理管控成熟度都将直接影响到微服务架构能否实施成功,要知道引入微服务架构后集成和后续运维等的复杂度都会成指数级增长。

简单举例来说,一个企业已经实施了5个业务系统,业务系统之间有10个接口。如果全部微服务化则可能设计到50个微服务模块,上100个接口和集成点。可想而知,在彻底实施微服务后,我们前期架构设计,后期集成和管控的复杂度增加10倍以上。

这种集成难度会远超大多数人想象,如果拿真实做的项目来说,如果谈业务系统只有3个,而到微服务模块级别则有接近60个,而实际涉及到的集成接口上1000个。我们做任何一个复杂端到端业务的联调基本就需要花2,3周甚至更长的时间。

互联网企业为何适合做微服务架构,其重要的一个原因就是互联网企业如电商平台,在进行了微服务化后各个模块之间耦合性很低,并不会有太多的集成和协同点。或者简单来说, 各个微服务模块更多的是向上面的PC端或APP端提供服务能力,而模块横向间接口协同很少。

正是在这种低耦合情况下,协同和集成相对来说容易。而转回到企业内部你会发现,在微服务模块化后,各个模块之间的集成点相当多,特别是业务系统拆分到模块或组件这一个级别后,很多原有内部的集成和依赖点全部暴露出来了,你都需要去很好的管理。由于这里面有大量的横向集成和协同点,因此导致的就是 微服务模块间的横向集成异常复杂,远超很多互联网应用,这是实际你会面临的问题。

企业信息化管理或业务系统的建设,根据企业自身IT管控能力和成熟度的发展必须要能够容忍灰度。就像一个企业招标建设了3个业务系统一样,刚开始一定关心的是三个系统能够运转起来支撑业务,同时三个业务间数据能够集成。你期望3个系统都安装统一的标准,框架,开发语言和组件化架构进行设计和交付,但是实际上却不可能,各个厂家标准和方法都不一样,厂家宣称的组件化设计而实际上内部模块仍然是强耦合在一起无法拆分。这些都是现实情况,需要容忍,即业务系统只要功能正常能和外面集成起来,其内部混乱一点我不太关心。

这和管理有时候是一样的道理,我们需要抓目标和过程,但是团队一大最上层领导就不可能管理到每个人。他更加关心的是下达给各个部门经理的目标能否很好完成,部门经理间协同上是否有问题。而各个部门经理管理的方法和流程容忍有差异,当企业的管理和治理水平不断成熟后我们再考虑如何更加精细化管理。

分而治之,一个事物能够分解到哪层?适合分解到哪层?是和你个人的能力和成熟度密切相关的。

一开始分解的粗,比如只分解到业务系统层面,刚开始就好管控,但是容忍了业务系统内部的一些杂乱无序。那么带来的问题就是当业务系统出现细粒度管控要求和能力扩展要求的时候,你会发现业务系统再要拆分为松耦合的组件并作到彻底的独立管理已经相当困难。这也是为何现在在企业内部也提微服务架构的原因。

企业IT成熟度不够而推行微服务架构,带来诸多的问题点,在下面一篇将详细分析常见问题。第3篇则讲企业微服务架构最好的切入点在哪里?

 

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

企业应谨慎对待微服务架构

- - 人月神话的BLOG
对于微服务架构我在前面很多文章里面已经都谈到过了. 微服务架构本质是 单个业务系统彻底的组件化(前端,逻辑层,数据库)解耦,同时相互之间通过轻量的服务接口和协议进行协同. 这和很早就谈到的组件化架构思想是一致的,实现微服务架构后,你会看到没有传统业务系统的概念了,有的只是微服务模块或小应用. 微服务架构最近又炒的相当活,很多人会说SOA过时了,ESB过时了,甚至还有人用微服务架构去彻底的否定SOA和ESB,这些都是相当危险的信号.

谈微服务架构

- - 人月神话的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,备注『加群』. 群里每周都有全球各大公司的最佳微服务实践以及行业最新动态.