这两年来,“微服务”、“云计算”、“大数据”、“人工智能”的概念在IT界成了新的宠儿:珠联壁合、声名远播、势如破竹、如日中天!从实践落地的情况来看:微服务诞生于互联网,当然是首先在互联网界遍地开花,高奏凯歌,所向披靡,到处布道。当传统企业刚遇到“微服务”,哇!这玩意真好啊,真是葵花宝典啊!业务隔离、独立部署、独立上线,高性能、高可用、弹性伸缩!我们公司要是也能实现这个该有多好啊!持续集成、持续部署,这不是我们整天喊整天吹的业务敏捷正需要的东东吗?然而在研究一翻之后,“洗洗睡吧!“ 抱着质疑的态度试试看的心态有之,唱反调嗤之以鼻的也有之,总之,进展不如人意!

去年有幸参与了一家国际巨头级大企业的微服务架构治理项目,在平衡了研发部门的一些阻力之后,通过坚持”适度自包含“的原则,还算成功!但“微服务”这个词,在火过一在段时间后,从这家公司的PPT中、公开演进中,基本不再提了,“微服务”这个词成了这个企业忌悔的东西。

下图的企业级IT采纳周期图,也说明了这个现实:

这里我们可能应该思考一下,为什么是这么个顺序?首先看互联网公司特别是巨头级电商,如阿里巴巴,从它的架构演进经历就可以看出,它是被业务复杂度、高并发、大数据逼出来的,从淘宝,到天猫,再到各类第三方渠道互联网产品,业务越来越复杂,周围聚拢的合作伙伴、合作伙伴的用户,企业用户、个人用户。不搞商品中心、店铺中心,不搞垂直切分,不搞微服务,不搞大中台,它就玩不下去了,所以是非常自然的。AWS也一样,本来是开电商卖书的,后来啥都卖,新的创意天天有,老板也OPEN ,云平台完全是一个意外的产物,所以它成了第一。亚马逊与阿里有一个共同的特征就是:老板不是IT人。而ORACLE,IBM,微软这些巨头就不同了,没有云计算、微服务之前,思考一下以前它们是靠什么赚取高额利润?商业套件+硬件服务器,这种组合方式,已经保证了ORACLE,IBM,微软近15年的高利润,它们当然不愿也不会轻易接受新事件的冲击了,它们属于不见棺材不落泪的类型,如果一直装鸵鸟,就会象诺基亚一样随风而去,中国联想也是一样,颓势愈发明显。而这些巨头的伟大之处就在于,虽然有质疑,但会敏感地关注,不断评判,往往在紧要关头,迎接挑战,最后扭转困局。比如微软是三巨头中最早一个看到危机的,所以Asure云平台现在市场占有率第二。

而对于企业来说,IT属于支持部门这个理念基本就没变过,三个月一上线周期是正常的,六个月也是有的,两个月一个大版本就是比较优秀了,两周一个小升级那就就是先进了。业务部门、销售部门对于企业来说永远是王者,其它部门都是支持部门,因为人家是直接看得到钱的。人怂志当然短了。对于IT研发、运维部门来说,少出事、别出大事、出了事与自己无关,那是绝对是自保基本三原则,那么对于IT新技术、新趋势的接受程度、落地速度,自然就是最慢了,如果没有顶层部门压下去,那是不可能跟上时代的。

大势所趋,趋之若鹜,再叶公好龙,再接受的慢,还是得拥抱"微服务"啊拥抱云!那么我该如何拥抱你呢?我的”微服务“。没别的办法,我们还要得思考,我们要用“微服务”改变什么?实现什么目标?

对于巨头级跨国公司,基本大并发高性能、大数据的需求都不迫切,大部分业务系统均为企业用户或内部员工,量级最多几十万,QPS1000基本就都可以打发了,数据量也不大,大量系统几年十几年了,数据库规模也是G级,一个ORACLE就装下了,它最大的诉求是什么,是直面激烈的市场竞争,和高压的销售任务,那么关键就找到了:如何在持复杂、持续变化的业务背景下,实现持续集成、持续部署、持续上线,实现真正的业务敏捷、随需而变。

在微服务化没出来的时候,这些企业的CIO也没少努力,可就是效果不大,或者压根不见效,SOA、敏捷、自动化测试,各种神器大展身手,那么败在了哪里呢?经过深度思考、分析,下面是它们的败点:

1、项目组织由不同部门组成,“部门墙”遗害无穷

2、项目组内是按技术架构分,而不是按业务,团队依赖严重、沟通成本高

3、SOA以最大复用为目标,层间依赖严重,未能隔离业务依赖,陷入依赖地狱

4、自动化程度差,开发、测试、试运行、生产环境的不同使QA质量不高

5、敏捷流于形式,未能有效隔离业务,工作量风险估计不足,敏捷不起来

各类神器既然都不见效,或者效果不明显,企业IT部门对新生事物当然会越来越抱着质疑的眼光,这玩意真的行吗?真能解决问题吗?还有,在大型企业特别是巨头级央企、私企, 无论IBM、ORACLE、微软、诺基亚、联想,都存在一个“尾大不掉”的问题,就是接受新事物慢、掉头慢、动作慢,对潜在挑战者的出现,往往在较长时间持鄙视的态度。如诺基亚对智能手机的三年鄙视,错失了追赶的时间,一败涂地,落个被收购的命运;IBM、ORACLE、微软之于云计算、AI,赶了个大早,起了个晚集,这里面微软省悟得还算快了一点,就这么一点也从AWS的云计算地位差了一大截。无法像阿里那样不断蚂蚁金服、菜鸟网络的涌现。所以领导人的思维很重要,领导人的换维眼光很重要,领导人的胆魄很重要,但如果象乐视贾跃亭那样只顾飞,不见陆地,有一天终会“啪”摔在地上。

那么我们回过头来继续思考,为什么传统企业IT负责人为什么对微服务有着叶公好龙一般的心态?,最根本的原因,仍是“尾大不掉:现有系统业务流程、应用架构、技术架构、产品UI经过多年打拼、打磨,付出大量加班和心血,已经稳定运行多年,可用性、稳定性已经到达一定高度,当然不忍打破了。因为打破之后的工作量风险、成本风险、质量风险、稳定性风险、周期风险,对部门业绩是一个挑战,因此在无上级部门强制要求,或者将架构重整当成考核指标的情况下,自然是稳定压倒一切,稳定压倒一切,稳定压倒一切.

没办法,大家首先要生存嘛,要生活嘛,不要风险!微服务的粒度细到一定程度,自包含很容易被打破,原有的强一致场景、一个SQL就解决的问题自然也被打破,UI交互甚至要重新调整、重新设计,服务层、数据层均要垂直切分,那么凭空会出来大量分布式事务,还要保持原来的强一致性(思维转变不过来),原来大量关联SQL很容易解决问题的,需要在数据库切分改后进行改造,数据模型不支持细粒度切分啊怎么办,加一个字段就可能影响许多点代码进行修改,重新测试,重构工作量不但大增,对系统原有稳定性也是一个打破和重建的过程,现有系统还要疲于奔命应付业务变化的情况下,“重构”成功了额外的工作,因此其重构的复杂性、工作量、风险都成了重大的阻力。

所以,以上才是传统企业IT负责人为什么对微服务有着叶公好龙一般的心态的核心因素。

所以无论是微服务,还是云计算,大型企业的接受肯定是排在最后,那么,如何转变呢?不是那么容易的,因为这是一个系统问题,微服务、DevOps、云计算,对大型企业的组织方式、管理方式、运营模式的冲击,是颠覆性的,我们看看有哪些颠覆性的元素:

1、微服务是对业务的垂直切分,那么对业务部门,也得垂直切分,方能实现业务隔离、业务敏捷,这是对业务部门动手术。

2、微服务是从需求-产品-开发-测试-运维的一体化,以细粒度的业务为单位,在大企业,这些环节往往由一个独立部门负责的,是对部门墙的打破。

3、项目团队按微服务团队,每个微服务要有业务持续性,有价值,这样这个团队才是活的,有价值的。

可以看到,这些颠覆性的元素,具有变革的性质,凡是变革,如果没有一把手的领导,没有顶层设计、监督、推进、执行,是不可能成功的。

传统企业IT为什么对微服务叶公好龙的心态?(转)的更多相关文章

  1. 传统保险企业基于 Dubbo 的微服务实践

    本文整理自中国人寿保险(海外)股份有限公司深圳中心技术总监家黄晓彬在 Dubbo 社区开发者日深圳站的现场分享. 中国人寿保险(海外)股份有限公司负责香港.澳门.新加坡和印尼的业务开发,和国内业务不同 ...

  2. 拷问传统企业CIO:微服务化值得吗?

    所谓数字化转型升级,就是以数字技术优化传统资源,企业需要谨慎地选择合适的技术逐步完成自己的数字化战略.以推出轻舟微服务平台的网易云为代表,云计算公司正在微服务领域发力,促进企业数字化创新.那么,微服务 ...

  3. 【分布式微服务企业快速架构】SpringCloud分布式、微服务、云架构快速开发平台源码

    鸿鹄云架构[系统管理平台]是一个大型 企业.分布式.微服务.云架构的JavaEE体系快速研发平台,基于 模块化.微服务化.原子化.热部署的设计思想,使用成熟领先的无商业限制的主流开源技术 (Sprin ...

  4. 【微服务】之六:轻松搞定SpringCloud微服务-API网关zuul

    通过前面几篇文章的介绍,我们可以轻松搭建起来微服务体系中比较重要的几个基础构建服务.那么,在本篇博文中,我们重点讲解一下,如何将所有微服务的API同意对外暴露,这个就设计API网关的概念. 本系列教程 ...

  5. .NET微服务调查结果

    .NET Core就是专门针对模块化的微服务架构而设计, 在2018年国庆时间展开.NET微服务的使用情况,本次调查我们总计收到了来自378个开发者的调查.从落地现状.架构体系.未来趋势等方面对微服务 ...

  6. 浅谈微服务架构、容器技术与K8S

    关注嘉为科技,获取运维新知 企业应用系统:从单体应用走向微服务架构:从裸金属走向容器. 如果在诸多热门云计算技术诸如容器.微服务.DevOps.OpenStack等之中,找出一个最火的方向,那么可能非 ...

  7. SpringBoot微服务

    在企业级软件的架构模型上,我们主要讨论下SOA与微服务架构. SOA的全称是Service-Oriented Architecture,可译为“面向服务的架构”,它是一个组件模型,将应用程序的不同功能 ...

  8. Re:从0开始的微服务架构--(二)快速快速体验微服务架构?--转

    原文地址:https://mp.weixin.qq.com/s/QO1QDQWnjHZp8EvGDrxZvw 这是专题的第二篇文章,看看如何搭建一个简单模式的微服务架构. 记得好久之前看到一个大牛说过 ...

  9. 微服务实践(七):从单体式架构迁移到微服务架构 - DockOne.io

    原文:微服务实践(七):从单体式架构迁移到微服务架构 - DockOne.io [编者的话]这是用微服务开发应用系列博客的第七篇也是最后一篇.第一篇中介绍了微服务架构模式,并且讨论了微服架构的优缺点: ...

随机推荐

  1. python框架之Flask(4)-上下文管理

    知识储备 偏函数 作用 偏函数,帮助开发者自动传递参数. 使用 import functools def index(a1, a2): return a1 + a2 # 原来的调用方式 # ret = ...

  2. 公众号获取unionid

    然后在微信客户端输入unionid接口的地址(比如发给文件传输助手www.XXX.COM/unionid.php),随便给别人发过去,在点击该链接,就能看到打印的accessToken,openid, ...

  3. 将指定世界中的指定位置的Block转化为箱子

    在bukkit中,block可以操作所有的三位像素方块,如果是向对block进一步操作,我们就需要得到BlockState, BlockState表示一个方块的状态,才能够对方块进行位置等状态的操作, ...

  4. phpcms列表页替换

    根据栏目代号获取栏目图 <img src="{$CATEGORYS[$top_parentid][image]}" width="1200" height ...

  5. usermod - linux修改用户帐户信息

    usermod - 修改用户帐户信息 modify a user account usermod [options] user_name usermod 命令修改系统帐户文件来反映通过命令行指定的变化 ...

  6. Key in_hidden/batch_normalization/beta not found in checkpoint

    可能原因:不同参数的结果保存到了同一文件夹下 解决方法:不同参数结果放在不同的checkpoints tf.train.Saver().save(sess, self.checkpoint_dir + ...

  7. Vue系列之 => 命名视图实现经典布局

    <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name ...

  8. ASP.NET页面之间传值的方式之Application(个人整理)

    Application  Application变量在整个应用程序生命周期中都是有效的,类似于使用全局变量一样,所以可以在不同页面中对它进行存取.它和Session变量的区别在于,前者是所有的用户共用 ...

  9. CSRF(Cross Site Request Forgery, 跨站域请求伪造)

    CSRF(Cross Site Request Forgery, 跨站域请求伪造) CSRF 背景与介绍 CSRF(Cross Site Request Forgery, 跨站域请求伪造)是一种网络的 ...

  10. Oarcle 入门之 order by 关键字

    order by 关键字 作用:用于对查询结果进行排序 select * from emp where deptno = 20 order by sal asc /desc; 如何排序之升降问题 *用 ...