精华内容
下载资源
问答
  • 技术中台的作用是什么? 技术前台 技术中台 在什么情况下,才有必要做技术中台? | 前提1:技术组织结构垂直化 | 前提2:业务线又多又复杂 有了技术中台,是不是就能上天? 总结 就在刚过去的半年里,「...

    目录

    技术中台的作用是什么?

    技术前台

    技术中台

    在什么情况下,才有必要做技术中台?

    | 前提1:技术组织结构垂直化

    | 前提2:业务线又多又复杂

    有了技术中台,是不是就能上天?

    总结


     

    就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要向中台转型!」的口号,甚至有人说「不做中台,那就等着死吧!」

    如果我没有记错,「中台」思想源自于2015年,马云参观一个著名的游戏公司Supercell之后提出了,简言之就是“小前台、大中台”,随即阿里就成立中台事业群,并取得了很好的成效。

    随后,美团点评也开始走中台策略,腾讯在去年的组织架构调整中,也提出建设具有 “腾讯特色的技术中台”。

    技术中台的作用是什么?

    要搞明白这点,你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系,以及他们各自扮演的角色与作用。

    先来说说我们的「技术前台」。

    技术前台

    「技术前台」,说白了就是为业务部门开发功能的技术团队。

    如果是ToC的业务,交付物必须贴近终端用户,如果是ToB的业务,交付物需要满足商家的需求。

    脑海中必须时刻牢记 “小步快跑,快速试错” 的理念,业务说啥,就是啥,业务要怎么做,你就怎么做。

    另外,研发资源的投入基本和业务对等,业务需求多,人数增加,业务需求少,人数相应减少,而且团队组织也基本按功能线来划分。

    运用的技术栈也相对单一,以Java语言为例,通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了,而其余的技术服务都将由「技术中台」提供。

    「技术前台」的核心价值体现在对业务逻辑的理解与实现上,是技术向业务传递价值的阶梯。

    我觉得在这点上,与线下销售团队的前台营销有一些类似。

    技术中台

    再来说说我们的「技术中台」。

    「技术中台」,说白了就是强调资源整合、能力沉淀的平台体系,当「技术前台」实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。

    这怎么理解?

    从这张图中可以看到,「技术中台」有点像编程时的适配层,起到承上启下的作用,将整个公司的技术能力与业务能力分离,并以产品化方式向前台提供技术赋能,形成强力支撑。

    在什么情况下,才有必要做技术中台?

    俗话说 “知己知彼,百战不殆”,在我看来,面对技术问题时,“知己” 比 “知彼” 更为重要。

    在实施「技术中台」之前,我们是否要静下心来对自己进行 “灵魂拷问”?比如说,当前的时机是否已经成熟?或者怎么才叫成熟?

    在我看来,要想做「技术中台」,客观环境需先满足两个前提:技术组织结构垂直化业务线又多又复杂

    否则,「技术中台」的结果只会是两种:一场闹剧 或者 一笔赔钱的买卖。

    | 前提1:技术组织结构垂直化

    曾经有朋友说过,每家公司的组织结构演进都是一部心酸血泪史。我很费解,问为什么?

    他说,因为这中间掺杂着太多的主观判断与情感纠葛。

    比如,某员工认为公司管理混乱,组织架构来回调整,今天拆这个团队,明天合那个团队,纯属病急乱投医,高管都是些横行霸道,滥用资源的傻逼货,借机搞人,这公司,没救了。

    但高管们大呼冤枉,觉得组织架构调整的目的是为了提高产出和人效,如果你干得不爽可以离开,这种事情,本来就不可能让每个人都满意,既得利益者肯定大加赞赏,而失去利益者肯定狂喷不止,不用理会。

    的确,这种 “自我革命式” 的调整,基本不可能一步到位,需要一个过程慢慢演化,而在这个过程里,自然会遭遇很多的阻力或质疑。

    瞧瞧这结构,经典的职能分工模式,有什么问题吗?

    我不但说不出问题,甚至能找出一万个理由说明这种模式的好处。开发按业务线分开,测试与运维形成上下层关系,谁也不想管对方,两边的老大也是评级的,相安无事

    那什么情况下才会觉得这种模式有问题呢?

    客观的说,职能分工模式更适合瀑布式开发模式。先谈需求,再谈工期,随后按部就班地往下做

    但当用户的需求开始变的多种多样,业务方时不时的就要上一个新功能,做一个新系统的时候,你会发现开发出来的系统很难变更,至少很难快速变更。

    于是,你把开发按系统功能进行重组,每个团队都围绕 “交付速度” 开展工作,但这样又遇到了两个新的问题:

    • 多种多样的中间件,每个团队独立选型中间件,没有统一的维护,没有统一的知识积累,无法统一保障SLA。

    • 开发与测试、运维之间目标不一致(比如测试A君,开发要求你只做功能测试,快上线,但测试老大却要求你做非功能测试,保障质量,避免背锅……到底听谁的?),陷入永无休止的扯皮与争吵。

    面对这两个新的问题,我们做出了调整:

    • 成立平台架构组,负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。

    • 把质量管理部中的测试团队,与系统运维部中的应用运维团队,按照系统功能拆分至各开发团队,由原开发经理负责,形成各自独立的Feature Team。

    到这个时候,虽然整个组织结构还未完全实现垂直化分工,但已基本能够达到 “快速试错,小步快跑” 的目标。

    另外,这更像平台化的另一种雏形,就是逐渐把一些公共、底层的技术能力抽象出来,与业务逻辑分离,并形成各种接入式基础服务,同时可以为多个业务线提供服务。

    也就是说,打造「技术中台」的前提是平台化,而平台化的先决条件是「组织结构垂直化,技术工具公共化」

    如果没有这样的前提,就失去了打造「技术中台」的立身之基。

    | 前提2:业务线又多又复杂

    曾经有朋友问我,技术的核心价值是什么?我的答案是 “改变世界”。

    他说,别扯淡,好好说话。

    他说,对业务驱动型的公司来说,技术的核心价值是 “降低成本,提升效率”,而单从架构设计的角度来看,想达成这项目标的两个手段是「通用性」与「复用性」

    现在想想,这句话可以完美的衔接到「技术中台」上去。

    回顾几年前,我们的业务逻辑也曾非常单一,要么用你的银行卡买卖基金,要么用你的电子钱包买卖基金,方便,快捷。

    渐渐地,随着业务创新业务增多,需要前后台系统定制开发,逻辑兼容难度增加。

    在这样的局势下,为满足企业规模扩大和多样化经营对组织机构的要求,公司开始转向事业部制,按产品、地区或市场(顾客) 划分经营单位。

    为了应对业务方的这次调整,我们开始将业务开发中的一些共享服务分离出来,成立了业务中台组(由于本文以技术中台为主,业务中台的内容将不进行展开说明)

    将可以复用的服务和代码,交由这几个组开发出服务来,给业务组使用,这样数据模型会统一,业务开发的时候,首先先看看有哪些现成的服务可以使用,不用全部从零开发,也会提高开发效率。

    与「业务中台」相呼应,「技术中台」就像一个工具大仓库,里面放满了各式各样的技术工具,无论是哪个团队,哪个人,快速找到自己的工具,拿来就用就行了。

    而维护工具的这群人,不用贴近业务开发,每天的任务就是研究如何使用这些工具,如何调优,遇到问题如何Debug,形成知识积累。

    有了这么一群专职的人,就可以根据自身的情况,选择有限几个技术栈集中研究,限定业务组只使用这些工具,可保证选型的一致性。

    如果你只有一条业务线,那就别搞「技术中台」了,把人凑在一堆,又省钱,又省力。

    有了技术中台,是不是就能上天?

    理论上讲,当业务线变多且越来越复杂,前台与后台之间的“技术债”会随之变多,重复造轮子与沟通成本太高的现象会增多,通过技术中台可以一定程度上来解决这个问题。

    这种理论看似完美,但在实际执行上却困难重重。

    设想下,如果「技术中台」做得太多,资源投入就会很大,无法形成正向的利益传导;

    如果「技术中台」做得太少,又无法深入理解业务,导致适配方案落地性变差,渐渐失去价值。

    这句话怎么理解?

    十年前,我在某金融软件公司工作,随着客户数的增多,成本与效率/质量的矛盾日益凸显。

    设想下,从一波人维护一套代码,渐渐变成一波人维护几套代码,这样一来,Bug增多,效率下降,抱怨也随之变多,再加上甲方挖人,最后人员离职,团队土崩瓦解,Game Over……

    在这种情况下,一般公司会采取三种应对措施:

    1. 一对一服务 - 项目制:多个团队,多套代码,多套标准,服务多家客户,但这样一来成本又难以承受,时间一长,肯定资不抵债。

    2. 一对多服务 - 标准化:一个团队,一套代码,一套标准,服务多家客户,但客户不买账,客户说我的需求都是个性化的,你别来某某标准来引导我,叫你咋做,你就咋做,不愿意?那您走,我找别人家做。

    3. 一对多服务 - 产品化:一个团队,一套代码,多套标准,服务多家客户,通过技术与配置化的手段,利用SOA思想,打造自己的产品化平台,但对技术投入要求较高,尤其是核心人才的依赖较大,中小型企业一般都很难留住这些人,只要他们一走,公司基本完蛋。

    回想下,当年那些叱诧风云的软件公司,又有几家活下来了?以金融业为例,恒生算是在第二条路上走的比较成功的,而我们当年却死在了第三条路上。

    在我看来,我们的「技术中台」就是一家 “乙方服务公司”,而我们的「技术前台」更像是一家 “甲方电商公司”。

    不可否认,有了这家 “乙方服务公司” 之后,在面对大型项目及快速多变的业务时,技术的投入与主动权更强了,但由于理念、职责、节奏与使命不同,外加 “屁股决定脑袋” 的立场,前台与中台之间很容易引发矛盾。

    从职责角度来说,前台是 “快速应对业务变化”,中台是 “稳定高效提供服务”。

    一个追求效率,一个追求质量,这矛盾是天然存在的。

    怎么理解?我来举个小例子说明下。

    前台部门的A团队和B团队,由于业务需要同时向「技术中台」提出要接入缓存服务的需求

    「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统,已在其他业务线运行多年,但由于A团队与B团队的技术债都各不相同,必须通过增加适配器才能完成接入

    而此时人手又不够,按重要程度排序,只能先接A团队,但B团队也有需求,又等不及,怎么办呢?就先给他来个Redis接着玩玩吧,等A团队接好了再来接你的。

    一个月后,等A团队接完了,找到B团队,这时痛点已不存在,团队的激情自然不高,毕竟没有收益,就不了了之了。

    几个月后,安全团队提出要对Redis集群进行改密,由于A团队接入的是「技术中台」的缓存中间件产品,采用代理模式,并通过控制台操作,既方便,又快捷,找个晚上,5分钟内,全部搞定。

    但B团队用的是直连Redis的模式,密码嵌入在SDK中,不仅在改密过程中需要前台与中台联动,而且还需要在改密后重启应用服务,这样一来,只有配合应用发布的周期才能干这件事。

    最终,原本五分钟可以搞定的事,整整搞了三周才搞定,「技术中台」的运维同学更是陪熬了多次通宵,还因为人为疏忽引发了一次事故。

    就在这件事过去的一年时间里,由于B团队系统的业务规模逐渐增大,Redis数量也逐渐增多,「技术中台」的运维成本与风险也随之上涨。

    这期间,中台曾多次与前台交涉,希望能够通过适配的方式将A团队接入缓存中间件,但始终未能达成。

    在「技术中台」看来,“你们只顾自己,不管别人,功劳你们拿,黑锅我们背?”

    在「技术前台」看来,“你TM懂个屁!我们都快被业务逼疯了,你们不就多费点人工吗?多加点班会死吗?总扯一些理念干嘛?对你没收益的事,你干嘛?”

    因为这样的分工模式,导致这种矛盾在工作中很多,而且似乎并没有更好的方法彻底解决。

    有人说,要解决很简单,要么强压,要么加大投入,下下狠心就得了。

    先来说说强压,似乎能够在短时间内达到目的,但纯属 “杀敌一千自损八百” 的招数,难道要业务研发团队停下手上的活,倾巢而出一起搞技术改造吗?更何况,前台承受的压力,是中后台团队无法想象的。

    退一步说,抛开 “互相理解” 这个话题,强压的套路等同于 “攻城为上,攻心为下”,对今后的管理与团队氛围都会带来诸多的麻烦。

    再来说说加大投入,看看我上面提到的 “死在路上的软件公司们”,还想加大中后台的投入吗?

    如果你不是大厂,还是算了吧。

    那句话怎么说来着?最悲惨的结局是,你的技术中后台越发强大,但你的业务规模却在逐渐萎缩。

    可悲,可叹。

    总结

    在互联网时代,技术圈似乎从来不缺少热议话题,但有质量,有深度,且能解决实际问题的却少之又少。

    现在人人都在讨论「中台」,今天「产品中台」,明天「数据中台」,这个说能提高效率,那个说能排除万难,聊得不亦乐乎。

    对于企业来说,话题热不热并不重点,方案牛不牛逼也不重要,关键是能帮助用户找到效率、质量与成本的平衡点,或许才算是一个合格的「技术中台」。

    展开全文
  • 公司技术成果无法有效沉淀,客户场景多样化导致定制开发成本高,产品化困难,面对这些痛点,一家AI公司该如何应对,也许技术中台是一个答案。这次分享的内容主要介绍了我们是如何通过容器化技术,结合AI公司场景特点...
  • 互联网技术中台

    千次阅读 2019-09-09 22:06:54
    在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地...

    定义

    在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
    在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
    在有些人眼里:中台应该是组织的事情,在释放潜能:类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”。

    中台更多是因为公司业务在发展到某一阶段时,遇到瓶颈与障碍后,为解决实际问题而提出的解决方案。

    1. 为什么需要中台?

    中台的产生,并非完全是自顶向下的战略设计,也非是为了追求某种行业风口,而是随着公司业务的高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决。而这时,中台的概念恰好对应了这个问题,所以大家接受了中台。

    1. 例:
      公司刚开始只有淘宝,后来意识到B2C模式的业务也会是电商领域重要的组成部门,所以出现了天猫,随着天猫的不断发展,逐渐独立成一个部门,但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立,各自运行。

    等到10年左右,阿里开始上线1688、聚划算等业务的时候发现,这些业务针对的领域虽然各不相同,但是他需要用到的系统功能也高度类似,主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍,这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求,为什么还要继续开发新系统呐?

    在这个大的背景之下,阿里内部将共享服务部的职权不断提升,统一将各个业务业务部门重复使用,反复建设的功能和系统统一规划和管理。
    阿里供应链中台/图源网络

    例2: 滴滴在15年末开始启动自己的中台战略,这与滴滴当时的业务发展阶段也是相关的。

    2015 年末,滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。

    这些业务虽然会有一些差别,但是核心系统和流程都是类似的。如果各自独立开发,也会出现各种各样的问题。

    比如说,开发成本过高,滴滴旗下的每个业务,其实都是可以单独支撑起一家公司的,如果每个业务都独立做到极致,那么开发成本和人力成本就会非常巨大,而如果为了控制成本,就把系统的建设放缓,则意味着,无论是核心系统本身的质量,还是对外的用户体验都不太好。

    在这样的背景下,滴滴也开始考虑将诸多业务,以及各个城市的系统统一规划,统一建设,提升服务前台的能力。

    其实,刚刚我们提到的,以及许多正在实践中台业务的公司,都有类似的问题,这些问题,大约会是两类——

    一类是,许多业务需求或功能需求高度类似、通用化程度很高,但是由于没有专门的团队负责规划和开发,大量的系统重复开发、重复建设,导致复用性低、效率低、产研资源浪费、用户体验不统一。

    另一类是,早期业务发展过程中,为了解决一些当下的业务问题,垂直的、个性化的业务逻辑与基础系统耦合太深,由于没有平台性质的规划,横向系统之间、上下游系统之间的交叉逻辑也非常多,这样导致在新业务、新市场的拓展过程中,系统没法直接复用,甚至没法快速迭代。

    这两类问题,在软件开发领域,有专门的名称,叫做“重复造轮子”和“烟囱式架构”。这两类问题本质上是企业在发展过程当中,为了解决当下的业务问题,快速上线了很多功能,而欠下了许多技术债,当企业进入成熟期之后,发现这些问题的存在,严重影响了企业的运行效率和运营成本。
    如何能够机制化,产品化地解决这些问题,能够更好地通过产品的形式,将企业内部具有很强的通用性的数据、功能、产品甚至经验进行统一规划和开发,进而更好地帮助前台业务部门更多地关注业务,提高业务运营效率,进而提升企业竞争力,是企业开发中台的基本出发点。

    现阶段,大多数提出中台战略或是建设大中台的公司,大多都有类似的困境。业务高速发展多年,许多问题积重难返或者大量在解决“重复造轮子”的问题,中台这个概念,很多情况下是因为契合了大公司业务的发展的情况,而被大家广泛认可。

    2. 中台能解决什么问题?

    很多公司的中台业务,实际业务发展到一定阶段,进入一个瓶颈之后,为了能够应对接下来的问题,才一点一点从内部开始推动解决之前的问题。
    但这其实只是中台建设的一个层面。

    中台作为一种产品设计思路,或者系统架构思路,并不受限于公司的规模,理论上讲,任何一家即将或者正在面临业务高速增长的状态时,都很值得利用和借鉴中台的思路,将目前业务当中大量可复用的功能和场景进行梳理,为业务的高速增长做好准备。

    这在中小公司当中,是有现实意义的。

    对于很多中小公司,当他们走出生存困境,进入到高速发展阶段时,会遇到很多的问题,但大概率会遇到的一个问题是,过往的业务模型,产品能力很有可能没法完全承接住大规模用户增长带来的压力。

    而当你具体到每个用户的时候,你又能发现,他们遇到的问题你之前都遇到过,只不过,因为一下来的太多,你没法像过去一样提供达预期,甚至超预期的服务时,对方就会产生不满。

    这也是为什么许多公司会生于拉新,死于留存的一个原因。

    很多公司在这个阶段的选择都是为了临时解决一个问题,快速上线一个功能,也不是不可以,只不过,很有可能你的解决方案会不断带来新的问题,最后陷入到功能太过复杂,以至于积重难返的地步。

    所以,在有可能的情况下,公司将一些大概率长期有价值的功能,专门模块化,进行开发和优化,确保即使业务规模进一步扩大,也能够满足业务需求。甚至,随着能力或方法论的不断优化,甚至有可能某一天成为整个行业的方法论。

    这个过程,就很像是在高速飞行过程中修飞机一样。一方面,机翼已经千疮百孔,摇摇欲坠,另一方面,发动机还在运转,你还能往前飞,但你知道,如果再进入到下一场战斗,你不见得还能确保飞机不会坠落,所以,必须抢在下一次战斗前把飞机修好。

    随着业务的发展,你对飞机的要求,也不仅仅是修好,可能会希望,能够提前预防一些问题。或者,知道你的飞机哪里战斗力最强,就把哪里做到最好。或许,就能够回避之后的一些问题。

    这或许是中台这个概念,对于中小公司内部产品规划的一个启发。

    当然,需要提示的一点是,对于中小公司而言,中台的理念不见得是单独拉几十人搭建一个中台产研团队,可以将一些关键流程先行标准化,把一些反复出现的场景当中的解决方案进行沉淀,部分需要产品化的功能先行产品化,可能对于一家业务刚刚开始起步的公司来说,就已经很重要了。

    3.中台产品经理的挑战

    一方面,是思维的差异。

    很多产品经理并不是从一开始就从事中台相关的事宜,也不是一开始就有中台这样的定位。更多情况下,他们是从前台业务部门,或者以业务为导向的产研部门转型到中台产研部门。

    这时,其实要面临很大的思维方式、做事方法的转变。

    在业务部门或者以业务为导向的产研部门,最核心的目的就是达成业务目标,要求你速度足够快、功能高效地解决当下的业务问题,当前业务发展的效率是最关键的。

    至于说,这个功能将来有没有可能适用于别的场景,有没有可能解决别的问题,这个问题实在是没那么重要。

    但是,对于中台不能如此。
    对于中台产品经理来说,必须思考的问题是,这个功能在现在或者将来能满足多少业务场景?如果将来有新的业务出现,是不是能够复用?或者说,需要做多大的调整才可以复用?甚至于,这个功能有没有可能对外输出,提供SaaS化的服务。

    另一方面,是环境的变化。

    当你在业务部门的时候,响应业务是相对轻松的。但是,在中台部门,响应多个业务,就没有那么轻松了。

    就拿需求调研为例。在业务部门或以业务为导向的产研部门的时候,你只要和对接的业务人员沟通清楚需求就OK了,毕竟,你只要了解这一个或对应的多个部门的业务需求即可,业务目标相对比较明确。

    但是,当你需要响应多个业务部门的时候,就没有那么容易了。

    你会发现,同样一个需求,A部门的流程和B部门流程完全不同,或者,流程是相似的,但到具体细节的时候,却有很大差异。

    更可怕的是,同样一个问题,由于业务的发展阶段不同,对于问题的态度也全然不同:有的部门业务已经非常成熟,自己流程也很清晰,所以不太希望你来调整他们现有的流程;但是,有的部门还处于探索期,还没有遇到你提出的问题,可能压根就不理你。这时,对于中台产品经理的挑战就非常大。
    他们可能会将大量的精力耗散于不同部门之间的沟通协调,反复对同一个需求进行确认,很长时间没有明显突破。这个时候,就要求中台产品经理有很强的沟通、协调和协作能力。
    并且,因为他们接下来要做的解决方案,是要服务于多个业务。这个时候,需要中台产品经理有很强的逻辑思考能力,看到不同需求之间的共性需求,并提炼出一个产品化的解决方案。
    甚至于,对于一些尚未遇到这个问题的业务部门,可能还要帮他们前置地思考解决方案。

    这又很要求产品经理的逻辑思考和抽象思考能力。

    既需要沟通协作的软技能,又需要逻辑抽象的硬思考,这可能才是中台产品经理最有挑战的地方。

    虽然有挑战,但是也不见得没有方法。对于中台产品经理来说,刚刚我们提到的内容,也只是帮助中台产品经理,对于中台产品这个岗位所要面临的挑战和工作,能够有一些初步框架性的理解。
    对于中台产品而言,他们的能力要求其实跨越非常大。一方面,需要极强的逻辑思维和战略分析能力,能够看到业务当中的关键流程,理解业务接下来的发展方向,并将其转化为产品功能,与研发一起实现。另一方面,又需要极强的沟通和交流能力,能够在与多个业务线,需求、背景、想法各不相同的相关方一起,推动完成相关功能的实现。

    展开全文
  • 文/技术领导力社区编辑/Emma阿里中间件高级技术专家 钟华、高级技术专家 泠茗、中间件技术专家 玄难,在公开分享和访谈提到阿里技术中台建设实践,包括:技术中台、移动...

    640?wx_fmt=jpeg

    文/技术领导力社区

    编辑/Emma

    阿里中间件高级技术专家 钟华、高级技术专家 泠茗、中间件技术专家 玄难,在公开分享和访谈中提到阿里技术中台建设实践,包括:技术中台、移动中台、业务数据双中台、研发中台、组织中台等等。

    本文整理了其中的PPT精华部分进行讲解,供大家学习参考。

    01

    阿里技术中台

    640?wx_fmt=jpeg

    (图片来源:阿里技术参考图册)

    技术中台,就是将使用云或其他基础设施的能力,以及应用各种技术中间件的能力,进行整合和包装。过滤掉技术细节,提供简单一致、易于使用的应用技术基础设施的能力接口,助力前台和业务中台数据中台的快速建设。

    阿里的技术中台,包括:

    流式计算

    • JStorm是一个分布式实时计算引擎,调度器分配一个worker 来跑任务,进行任务全生命周期的托管。

    分布式存储

    • Tair(Key/Value结构数据存储系统)

    • Histore(分布式海量数据场景下OLAP分析型数据库产品)

    • Hbase

    • TFS(分布式文件存储)。

    分布式数据库

    • TDDL(分布式数据库中间)

    • 精卫(取名自“精卫填海”,基于MySQL数据库的数据复制组件)

    • 愚公(数据自动迁移引擎,异构数据源迁移)

    • SchedulerX(分布式任务调度)。

    消息

    • Notify

    • MeteQ

    分布式服务

    • HSF(High Speed Framework,分布式服务框架,当时阿里内部选择了HSF,放弃了dubbo)。

    负载均衡

    • Tengine(是基于 Nginx 开发的轻量级开源 Web 服务器,作为阿里巴巴七层流量入口的核心系统)。

    应用容器

    • Pandora(是淘宝网中间件团队打造的,基于HSF隔离技术构建的全新一代隔离容器)。

    软负载&配置中心

    • ConfigServer(主要提供非持久配置的发布和订阅)

    • Diamond(是一个持久配置管理中间件,可以实现分布式场景下,中心化的持久配置管理,同时也支持基于发布订阅模型配置动态变更推送)

    • VipServer(天枢,通过集中式的配置向客户提供路由信息,以非网关的形式实现负载均衡功能)

    • Zookeeper。

    分布式链路跟踪&基础数据

    • Eagleye(鹰眼,通过收集和分析在不同的网络调用中间件上的日志埋点,可以得到同一次请求上的各个系统的调用链关系,有助于梳理应用的请求入口与服务的调用来源、依赖关系)

    • TLOG(是一个分布式的,可靠的,对大量数据进行收集、分析、展现的的系统)。


    02

    阿里移动中台EMAS

    640?wx_fmt=jpeg

    阿里巴巴高级技术专家泠茗,分享到,阿里的移动中台是构建在业务&数据中台之上,为更好更快地利用中台能力、快速迭代移动端产品,又生生地挤出(或是说沉淀)出了一个新的中台层。

    移动中台建立在业务数据双中台之上,更靠近移动前端战场,我们可以类比成战场上的坦克群,近距离支撑一线战场。


    640?wx_fmt=jpeg

    在端技术方面,采用RN搭建技术框架,支持Hybrid,并且自研了排版引擎,包含安全组件、离线数据、JS桥接框架等,支撑了淘宝、天猫、支付宝、盒马、咸鱼、飞猪、钉钉等App应用。


    640?wx_fmt=jpeg移动中台,通过搭建移动框架体系,支持各种不同业务场景,让非技术人员快速完成业务,集成了AI生成页面、模块开发体系、国际化、统一登入/权限等,支持对业务的快速响应。

    640?wx_fmt=jpeg

    移动中台不仅提供前端技术框架,还支持后台系统快速搭建,通过场景化组件体系,提供三深三式设计框架、场景组件、适合供应链系统的组件解决方案。


    03

    阿里的研发中台

    640?wx_fmt=jpeg

    研发中台,主要关注与开发效能管理,软件开发是一项工程,涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”,从而助力创新性应用的快速开发迭代,也是我们看到的很多企业正在做的事情。


    640?wx_fmt=jpeg

    如果说技术中台为前台应用提供了基础设施重用的能力,那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。

    阿里效能部,一直致力于集团研发效能的提升,通过工具、规范、体系给各业务线开发团队赋能。


    640?wx_fmt=jpeg

    研发中台,其中不得不提的是“全链路压测”平台Amazon,每年“双11”前夕承载着大量压测任务,提供了全量线上压测、混沌工程等复杂场景下的压测实践。


    04

    阿里数据中台

    640?wx_fmt=jpeg

    阿里数据中台产品包括:OneData、OneID、OneService、Dataphin等等。数据中台的内容在上期文章中详细讲过,感兴趣的同学可以查看文末链接前往阅读。

    05

    阿里的业务、数据“双中台”

    640?wx_fmt=jpeg

    古谦在云栖大会《企业核心业务数字化转型最佳实践》分享,阿里的数据业务双中台堪称经典。从图中可见,阿里中台主要体现为由业务中台和数字中台并肩构成的双中台,并肩扛起了所有前台业务。

    业务中台将后台资源进行抽象包装整合,转化为前台友好的可重用共享的核心能力,实现了后端业务资源到前台易用能力的转化。

    数据中台从后台及业务中台将数据流入,完成海量数据的存储、计算、产品化包装过程,构成企业的核心数据能力,为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。

    业务中台与数据中台相辅相成、互相支撑,一起构建起了战场强大的后方炮火群和雷达阵。


    06

    组织中台让阿里致胜千里

    640?wx_fmt=jpeg

    组织结构是企业的生命底色,企业作为组织生命,生命天生追求稳定性,个性化的消费者天生追求个性与多样性,在两者的对立统一中,如何建立一个兼具稳定性和多样性的组织生命体是我们探讨的核心命题。

    而中台建设真正困难的是组织上的重构,这往往是大家有意无意避而不谈的。

    中台战略的成功、能否实现技术架构与组织架构的匹配,是一道绕不过去、但必须要迈过的门槛。从阿里成立共享事业部,海尔的人单合一、职能并联,到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。


    07

    中台战略在企业中如何落地?

    640?wx_fmt=jpeg

    中台战略能解决未来问题,是一种能力沉淀,是企业数字化转型的最佳落地实践,可以让企业持续前进、加速奔跑。

    第一,实现从局部优化到全局优化的转变。鞋服行业追求高库存、高消耗,所有关注点都在供应链,就需要把WMS或者供应链做到足够优化。此时的优化一定是局部的,一是部门没办法控制营销端的事情,二是营销端的数据不够实时。而今天,在中台战略的助力下,企业可以在整个架构下进行全局优化,实现最大化的优化效率。

    第二,能实现企业业务数据实时、统一、在线。很多企业组织中会碰到业务响应的问题,其实90%是因为你的数据没有做到实时、统一、在线。比如说,销售部门想要看到7000家门店销售数据如何,供应链怎么优化,商品设计能不能做爆款预测等,但彼此间的数据是割裂的,系统间协同效率低,实时统一在线性极弱,所以很难将这些想法落地。而如果企业只有一份数据,包括电商环节、供应链环节,就能够发现任何一个场景下对于业务的变化和感知,实时联动。

    第三,实现更具“韧性”的企业架构。康师傅如今被打击得无还手之力,但打击它的不是统一这样的同行业品牌,而是外卖。今天,外部环境的变化是不可预测的,而中台战略可以让企业架构更具“韧性”,能面对多变的环境迅速调整,快速“重生”。

     08

    大中台团队的KPI怎么考核?

    640?wx_fmt=png

    大中台是个上不顶天,下不立地的组织。不能简单的按照业务和收入KPI进行考核,因为能做多少收入不是它能掌控的,毕竟它是个能力和成本中心,不是个利润中心,又不能按照IT系统的方式去考核它,否则离业务太远,资源整合的业务价值没法体现,同时你还不能简单的以一年为单位来考核它,因为能力中心的建立不是一朝一夕之事,你按年考核它,它就会急功近利。

    另外,国内的企业管理者技术出身的比例不大,对于中台的理解有限,传统企业有几个CEO是真正懂的,一定程度上造成业务人员高人一等的现象。毕竟KPI为王,企业大多数时候,还是屁股决定脑袋的,但做百年老店拼的不是起跑线,而是谁的耐力更久,在移动互联网时代更是如此了。

    09

    如何评判一个平台是否称得上中台?

    640?wx_fmt=jpeg

    让我们引用一段阿里玄难在接受极客公园采访时提到对于中台的一段我非常认同的描述:

    本文中我们一直提到的一个词就是“能力”,从玄难的这段采访也可以看出,在阿里,“能力”也是中台的核心。

    一切以“以用户为中心的持续规模化创新”为目的,将后台各式各样的资源转化为前台易于使用的能力,帮助我们打赢这场以用户为中心的战争的平台,我们都可以称之为中台。



    10

    本文内容小结

    1,技术中台提供了自建系统部分的技术支撑能力,帮助我们解决了基础设施,分布式数据库等底层技术问题,为前台特种兵提供了精良的武器装备。

    2,移动中台提供了战场一线火力支援能力,帮助我们提供更加个性化的服务,增强用户体验,为战场提供了陆军支援能力,随机应变,所向披靡。

    3,业务中台提供重用服务,例如用户中心,订单中心之类的开箱即用可重用能力,为战场提供了强大的后台炮火支援能力,随叫随到,威力强大。

    4,数据中台提供了数据分析能力,帮助我们从数据中学习改进,调整方向,为战场提供了强大及时的雷达监测能力,帮助我们掌控战场。

    5,研发中台提供了自建系统部分的管理和技术实践支撑能力,帮助我们快速搭建项目,管理进度,测试,持续集成,持续交付,是前台特种兵的训练基地及快速送达战场的机动运输部队。

    6,组织中台为我们的项目提供投资管理、风险管理、资源调度等,是战场的指挥部,战争的大脑,指挥前线,调度后方。



     -End- 



    “阿里中台”系列其它3篇:

    1.阿里数据科学家一次讲透数据中台,15页PPT精华

    2.阿里架构总监一次讲透中台架构,13页PPT精华详解

    3.学阿里中台,就要学最值钱的部分:中台建设方法论!


    想下载文章中的PPT?第一步,关注“技术领导力”公众号第二步,在对话框输入:中台

    640?wx_fmt=jpeg

    想跟文章作者、100位互联网大咖交流学习?

    添加助理小姐姐Emma

    注明“加群”,稍后她会拉你进社区群

    640?wx_fmt=jpeg


    往期精彩推文:

    1.男,40,总监,失业,中年人,愿你终能体面的离开

    2.90后美女CEO想找个CTO,我给她个技术经理

    3.我用了10年,从深圳工厂妹到Google程序媛

    4.来做技术总监吧.要写代码吗?不写你来干嘛

    展开全文
  • 中台架构实际由若干个层次组成,其中微服务技术中台是构建中台架构的重要组成部分。SpringCloud和Kubernetes,是目前互联网企业构建微服务技术中台所采用的主流技术栈,波波也会分析和比对这两个方案。Kubernetes...

    前言

    中台架构一词最近在技术圈内比较火,波波基于自己的经验和视角,也来凑个热闹聊聊什么是中台架构。中台架构实际由若干个层次组成,其中微服务技术中台是构建中台架构的重要组成部分。SpringCloud和Kubernetes,是目前互联网企业构建微服务技术中台所采用的主流技术栈,波波也会分析和比对这两个方案。Kubernetes平台封装了构建微服务技术中台所需的关键基础服务,它是波波推荐的,构建微服务技术中台的一个比较完备的基础方案。

    什么是中台架构?

    中台这个概念其实在国内最早是由阿里巴巴提出[参考附录1],原来主要是个业务和组织的概念。2015年,阿里提出构建DT时代的更灵活创新的“大中台、小前台”的所谓中台战略,强调组织业务和技术能力的抽象沉淀、模块化和重用,从而对各前台业务形成强力支撑,使得前台一线业务能够更敏捷、更快速适应瞬息万变的市场。从具体架构上讲,阿里的中台架构可以简化分为四个抽象层次,如下图所示,从下到上依次为:

    • 第一层(最底层)是基础设施服务层IaaS(Infrastructure as a Service),负责计算、网络、存储、监控、发布、机房和数据中心等基础设施。
    • 第二层是技术平台服务层TPaaS(Technical Platform as a Service),负责中间件、大数据等基础服务和研发工具链等。第一二层在阿里体系中统称为技术中台。
    • 第三层是共享业务服务层BPaaS层(Business Platform as a Service),是阿里多年研发运营沉淀下来的商业能力模块(包括用户,商品,店铺和营销等等),被抽象封装成公共服务,供上层调用和集成,阿里把该层也称为业务中台。
    • 第四层(最上层)是业务前台层,按照不同业务线(淘宝、天猫和聚划算等)划分,再根据不同用户体验渠道(PC,无线和第三方接入等)构建不同的用户接口层。

    阿里中台
    所谓“大中台、小前台”,就是要强化技术和业务中台的建设,把中台打扎实,才能支持并且赋能前台业务线快速迭代和创新。换句话说,有平台才有生态,只有把中台的土壤夯实,才能让前台的生态变得更加茂盛。

    当一家互联网公司发展出中台以后,它的商业规模化能力就会比较强大。比方说阿里,原来它有淘宝、天猫和1688等核心业务线,之后它再扩展出其它业务线(比如阿里妈妈、菜鸟物流和阿里去啊等)就很快,因为它可以重用底层的这些技术和业务中台能力。相反,对于一些没有发展出中台的公司,它的商业拓展能力就会比较弱,每次拓展新的业务线可能需要从零构建这些底层的技术和业务能力,明显缓慢而且很累。这个可以和航母平台化作战体系做一个类比,我们都知道目前美国拥有世界上最庞大的航母战斗群,所以它的作战投射能力非常强,今天把航母拉到中东波斯湾,明天又拉到他国领海,很快能形成战斗威慑力,这就是大规模平台化作战的优势。

    航母平台化作战体系

    中台架构不仅阿里有,其它一些大型互联网公司也有,比方说eBay,下图是eBay的中台架构[参考附录2]。我曾经在eBay中国研发中心工作过,最早看到这张eBay中台架构图是在2008年左右,也就是说,在2008年前,eBay就已经具备了比较完善的中台架构。eBay的中台架构和阿里的大致是类似,也是分为对应的四个层次,只是各层的具体称谓有些区别。

    eBay架构

    阿里或者eBay的中台架构,实际也不是一开始设计出来的,而是不断演进出来的。这些公司都经历过不断重复造轮子和造烟囱的阶段,最终发现这样做不仅不可持续,更无法规模化,最终都演进到模块化和重用的中台架构,也就是说,中台架构是业务可持续发展和规模化的必然产物

    中台架构,可以作为互联网企业组织和系统架构的一个参考模型。构建类似阿里或eBay级别的中台门槛很高,资源和人力投入大,而且需要多年的沉淀和积累。但是我们可以学习借鉴阿里或者eBay的中台架构的思想,然后根据企业实际业务的规模、资源和投入的情况,构建轻量级的中台,来支持业务快速迭代和创新。下图是我在拍拍贷工作期间,根据拍拍贷的业务和组织情况,参考eBay的中台架构,设计的面向拍拍贷的轻量级中台架构[参考附录3]。

    ppd中台架构

    中台的抽象层次较高,和企业的战略、组织架构密切相关,是企业中高层和架构师需要理解和掌握的。对于一般的开发人员来说,其实并不需要急于去学习中台架构,简单了解即可。但是,对于一般的开发人员,如果后续想往架构或者管理方向发展,可以先从学习和掌握微服务技术中台开始。

    微服务技术中台公共关注点

    微服务架构的思想原本和中台架构没有直接关联,但是如果你有经验的话,你会发现微服务架构和中台架构是密切相关,并且可以相互映射的。同样以上图阿里的中台架构为例,中台架构的第一二层,可以对应称为微服务技术中台,而中台架构中的第三层,则可以对应称为微服务业务中台。对于微服务业务中台,我们并不展开,我们来聊聊微服务技术中台该如何构建?要回答这个问题,我们先要理解微服务技术中台到底要解决哪些技术问题,也就是所谓公共关注点(concerns)。下图总结这些公共技术关注点:

    微服务公共关注点

    具体讲,这些关注点包括:

    1. 配置管理:对微服务应用的可变参数进行配置。这些参数可以是启动期一次性配置的,例如数据库连接字符串,也可以是运行期动态配置的,例如调整缓存TTL过期时间,业务促销限购数量等。
    2. 服务发现和负载均衡:服务分布在不同的节点上,服务之间要相互调用,首先要定位找到对方,这个就是服务发现,它是微服务架构的基本问题。另外,服务一般以多实例方式部署,调用方需要以某种负载均衡策略去访问目标服务实例。
    3. 弹性和容错:分布式微服务通过网络互联,网络有可能不稳定,服务实例有可能延迟、出错甚至宕机,微服务系统必须具备弹性和容错能力,才能保障服务质量和用户体验。
    4. API管理:这里主要指微服务系统对外暴露API,一般通过API网关进行管理。网关是微服务的大门,需要支持反向路由、安全鉴权、日志监控和限流容错等基本功能,高级的网关要支持A/B、蓝绿和灰度测试等高级功能。
    5. 服务安全:用户访问微服务首先需要认证,对某些敏感的服务进行操作还需要鉴权,服务之间调用也需要一定的权限管控。
    6. 日志监控:服务访问日志需要集中进行采集、存储和分析,方便后续进一步分析微服务性能,甚至是用户行为。
    7. Metrics监控:对微服务的调用需要进行Metrics埋点监控。Metrics监控既可以对服务性能(调用量、延迟、错误数)等进行监控,也可以对重要业务指标(如登录数、下单数等)进行监控。
    8. 调用链监控:分布式微服务之间的依赖关系错综复杂,通过调用链监控能够实时掌握微服务之间的依赖关系,服务之间调用的性能,出现问题时能够通过分析调用链及时排障。
    9. 调度和发布:微服务最终需要发布到生产环境中,目前推荐的微服务交付手段是容器云环境,容器云需要支持自动的容器资源调度和发布,高级的需要支持滚动(rolling update)、蓝绿(blue-green)等发布机制。
    10. 自愈和自动伸缩:云环境中的节点实例有可能宕机或漂移,网络可能随机不稳定,微服务平台需要有自动侦测问题和自动恢复的能力,这个就是自愈(self-healing)能力。另外,用户流量可能会突发骤增,理想情况下,微服务平台需要能根据用户流量的变化自动伸缩(auto-scaling),节省硬件资源同时又不影响用户体验。

    关于上述公共关注点中的前面8个点,波波和极客时间合作的课程《微服务架构和实践160讲》,对架构原理和开源产品有深度剖析,欢迎有兴趣同学进一步学习。

    如果把微服务的上述公共关注点抽象、封装和沉淀下来,最终产出的软件产品,就称为微服务开发框架/平台。SpringCloud和K8s,分别是Netflix(+Pivotal)和谷歌,两家公司各自演进、沉淀并开源贡献给社区的解决方案。

    Spring Cloud和Kubernetes横向比对

    前面我们讲到,SpringCloud和K8s,分别是Netflix和谷歌,针对微服务公共关注点给出的解,只不过它们两家的解法和侧重点有所不同。这里有两个表,通过这两个表,我们对SpringCloud vs K8s所支持的功能点,做一个全面的横向比对:

    sc_vs_k8s_1

    1. 服务发现和LB:服务发现和LB是微服务基本问题,两家都给出了解决方案。SpringCloud的服务发现主要引用Netflix的Eureka,配合使用Ribbon实现客户端发现和软负载。K8s则直接在平台层解决这个问题,它直接在平台中引入了Service这个抽象概念,屏蔽了底层服务发现和负载均衡细节,让应用开发和服务框架都不需要关心这层细节。
    2. API网关:这层SpringCloud主要引用Netflix的Zuul网关,它是经过Netflix大流量考验的一个成熟产品。在K8s体系中,和网关对应的概念叫Ingress,它定义了一些规范,具体可以采用各种实现,例如Nginx、Envoy或者Traefik等,都可以做Ingress。
    3. 配置管理:这块SpringCloud有Spring Cloud Config对应产品,实现比较简单,后端基于git进行配置管理。K8s则在平台层内置支持ConfigMaps/Secrets等配置机制,配置可以通过环境变量注入容器中,也可以挂载到容器文件系统中。
    4. 限流容错:这块SpringCloud支持Netflix开源的Hystrix容错限流组件,Hystrix在Netflix平台稳定性方面发挥了巨大作用,它已经成为业界限流熔断的一个标配。K8s平台内置支持健康检查(HealthCheck),启动就绪探针(Probe)等容错机制,如果需要细粒度流量控制,则需要引入ServiceMesh机制进行配合。
    5. 日志监控:这块两者都没有单独的开源产品,不过社区已经有ELK(Elasticsearch/Logstash/Kibana)这样的成熟标配解决方案,两者都可以直接集成。K8s推荐使用Fluentd进行日志采集。
    6. Metrics监控:SpringCloud支持MicroMeter/Actuator等机制,可以采集和暴露Metrics指标,方便对接Prometheus等监控告警系统。K8s内置支持MetricServer,可以采集K8s平台内部资源性能指标,方便对接Promethues,如果要进一步监控应用层性能指标,可以引入ServiceMesh配合支持。
    7. 调用链监控:这块SpringCloud提供Spring Cloud Sleuth,支持对接Zipkin调用链监控。K8s推荐采用Uber开源的Jaeger进行调用链监控,也可以使用Zipkin。

    sc-vs-k8s-2

    1. 应用打包:SpringCloud支持嵌入式容器+Uber Jar方式打包,方便应用发布和运行。K8s则直接支持容器镜像部署,它不关心容器内部的具体应用形式。K8s还支持Helm这样的应用级打包标准,可以实现应用商店。
    2. 服务框架:Spring本质上是一种HTTP/REST框架,比较松散简单,开发测试都友好。K8s是一个平台,它是具体框架无关的,它只认容器,不同语言栈(Java/Go/Python/Node/Ruby等等)的各种框架都可以住在K8s里头。具体语言栈无关是K8s区别于其它服务框架的最大亮点
    3. 发布和调度:这块SpringCloud没有单独考虑,而是交由运维去解决。K8s平台本身重点解决的问题就是服务发布和容器调度。
    4. 自动伸缩和自愈:这块SpringCloud没有单独考虑,而是交由运维去解决。K8s具备自动故障检测和自愈的能力,自动伸缩需要引入额外组件,完全实现有一定的技术门槛。
    5. 进程隔离:这块SpringCloud没有单独考虑。K8s通过容器进行进程隔离,同时还引入了Pod进一步对服务进行隔离。
    6. 环境管理:这块SpringCloud没有单独考虑。K8s内置支持Namespace进行逻辑隔离,可以实现多环境,各个环境可以单独配置认证授权机制。
    7. 资源配额:这块SpringCloud没有单独考虑。K8s支持对CPU/Memory进行使用量限制,也支持Namespace级别的配额管理。
    8. 流量治理:主要指高级流量调度,A/B和蓝绿部署等能力。这块SpringCloud没有专门方案。K8s则需要引入ServiceMesh配合支持。

    Spring Cloud和Kubernetes优劣比对

    经过比对,大家应该对SpringCloud和K8s这两个产品的功能点,应该有比较全面的了解了。下面我们对这两个产品的优势和不足,再进行一个比对:

    sc-vs-k8s-3

    SpringCloud是Spring框架和NetflixOSS的融合的产物,它同时吸纳了两者的优势。Spring框架有超过十年历史,是开源界的一个传奇。Spring框架社区异常活跃,框架本身成熟灵活,开发者体验好是最大亮点,背后有Pivotal公司提供专业支持,不断完善和推陈出新。NetflixOSS是现代微服务架构大胆创新产物,同时也经历过Netflix大流量冲击洗礼。Netflix框架的一大亮点是抽象和组件化做的比较好,可以像搭积木一样灵活组装微服务基础设施,而且可以灵活替换。SpringCloud的不足主要是仅限于JVM语言栈,其它语言栈支持非常有限。另外,SpringBoot因为封装较多,运行起来比较吃资源,尤其是跑在容器里的时候。

    K8s和SpringCloud的主要差异在于,它是从平台层解决微服务基础设施问题的,抽象层级更高,它一次性解决了服务自动化发布的难题,而且它做到具体服务框架无关,可以容纳各种语言栈框架。可以认为,SpringCloud仅解决了微服务基础设施的部分问题,而K8s则是一个完整的微服务基础设施解决方案,所以,K8s是构建微服务技术中台的推荐基础方案。K8s背后有谷歌支持,社区异常活跃,被认为是未来的数据中心操作系统,云原生应用的标配。K8s的不足是它是一个更偏向DevOps和运维的平台,比较重量复杂,技术门槛相对比较高,一般的中小公司可能hold不住。

    简单做个比喻,SpringCloud是组件化的,如果比喻建房子的话,就是自己买建筑材料自己建房;K8s是平台,如果比喻建房子的话,就是开发商承建的商品房,用户购买后拎包入住即可。

    我的建议

    经过上面的比对,大家对SpringCloud和K8s所支持的功能点(也就是它们所解决的微服务公共关注点),以及这两个产品的优劣和不足,应该有进一步的理解了。那么我们到底该如何选择呢?这里我给出一些建议。

    首先,这两个产品都有大规模成功落地案例,没有绝对的好坏。作为架构师,重要的是理解这些框架背后的SOA/微服务关注点,理解这些产品如何解决这些关注点,它们各自的优势和不足,然后根据企业实际上下文(发展阶段、业务、技术架构和团队等)综合考量。

    在此基础上,波波会有自己的个人倾向,波波比较看重两点,一个是社区生态,毕竟随大流比走冷门要轻松很多,另外一个是对微服务公共关注点考虑的全面性,我不想自己再花费精力去解决自动化发布等繁琐的事情。综上,我比较倾向K8s平台+SpringBoot框架,这两个是目前社区的绝对主流,可以用如日中天来形容,K8s是针对微服务公共关注点最完备的解决方案,服务框架我倾向直接用SpringBoot,我不需要SpringCloud那套,因为它支持的功能K8s已经覆盖了很大部分。另外,考虑到K8s技术门槛和运维成本高,对于一般的中小公司,我不倾向自建K8s,而是建议直接采用公有云K8s(例如阿里云K8s),把K8s运维的活外包给阿里云(开发商)。

    在波波和极客时间合作的最新课程《SpringBoot与Kubernetes云原生微服务实践》中,波波会结合具体案例Staffjoy教学版开源项目,教大家如何基于SpringBoot,架构、设计和实现面向云原生的微服务应用,并最终部署到阿里云K8s环境,欢迎感兴趣的同学关注学习。

    在这里插入图片描述

    课程案例项目架构
    在这里插入图片描述

    课程案例项目部署到阿里云K8s的部署架构
    在这里插入图片描述

    附录

    1. 阿里巴巴全面启动中台战略

    2. eBay Architecture

    3. 拍拍贷中台架构

    4. Staffjoy教学版开源项目

    展开全文
  • 前台、后台我知道,中台是什么呢? 今天一早起来,整个互联网圈都被腾讯的组织架构调整刷屏了,甚至有些人对腾讯新的6大事业群如数家珍,侃侃而谈,搞得比对自家公司的组织架构还清楚一样。 腾讯进行组织架构调整...
  • 另一方面,云计算等技术的进步为SaaS发展提供了基础设施和底层技术。”十月底腾讯发布SaaS生态“千帆计划”,腾讯云副总裁答治茜如是说。 在此之际,腾讯也首次披露其在SaaS领域的打法,SaaS市场要迈向新高度,...
  • 中台技术简介

    千次阅读 2019-12-24 16:35:06
    中台技术全景 移动中台 业务中台 技术架构图 技术选型 ServiceMesh... 数据中台 技术中台技术组件的高可以部署及多租户问题的解决。 redis,mq,db...... 研发(效能)...
  • 浅谈企业IT技术运营中台

    千次阅读 2019-03-11 09:30:23
    如果你是IT圈内的人,在2月份,你的朋友圈里面最火的词应该就是“中台”了,我们在此不讨论企业的技术中台、数据中台、AI中台、业务中台,想和大家讨论一下IT技术运营中台。 “技术运营中台”,我们可以理解为...
  • 火爆技术人的中台是什么?如何搭建中台?如何选择?还有经典案例分享
  • 首先先上张技术中台架构图 概念 中台概念出现之前,在信息化模式上,前端为支撑业务的应用端,后端为各个应用系统,为前端用户,如:客户、供应商、伙伴、社会,提供服务,但随着市场、用户需求、业务的多变性,...
  • 数据中台技术架构方案

    千次阅读 2020-06-28 00:00:00
    点击上方蓝色字体“肉眼品世界”,关注公众号深度价值体系传递数据中台技术架构:来源:方案经理 ...
  • 接着上篇继续讲,接下来主要介绍交易总体设计的技术要点设计,对于电商中台来说,交易系统是核心的核心,一开始就需要围绕高性能,高可用,和高扩展三个方面来重点设计。本篇主要介绍高性能设计。 对于高性能的...
  • 漫谈中台产品

    千次阅读 2019-12-30 23:46:33
    在有些人眼里,中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。 在有些人眼里,中台应该是组织的事情,在释放潜能:类似于企业内部资源调度中心和内部创新孵化...
  • 中台框架图

    千次阅读 2019-10-08 11:46:45
    一般项目架构图: 淘宝中台 游戏中台 业务中台 技术中台 数据中台 算法中台
  • 白话解读“中台技术

    千次阅读 2019-08-14 12:47:58
    什么是中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台。什么是中台中台诞生任何一个软件系...
  • 导读:中台的存在价值是为它的客户服务,比如业务台和数据中台要快速响应前台应用的需求。 但如果中台同时服务于多个前台应用,在资源有限的情况下,必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台...
  • 如何搭建企业中台

    千次阅读 2019-08-10 22:53:09
    1.解读一:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,我们叫它“技术中台”。 2.解读二:中台就是一组公共的微服务平台,像最常见的什么用户中心、订单中心、商品中心等等,各种...
  • 一文读懂数据中台技术架构

    千次阅读 2020-11-02 22:11:52
    一文读懂数据中台技术架构 https://www.toutiao.com/i6836923386560512516/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1603853943&app=news_article&utm_source=...
  • 何修峰,就职于滴滴业务中台,任高级技术专家一职,致力于微服务治理、提高系统工程效率、构建底层基础组件或服务,在大型分布式系统构建、微服务治理、复杂系统重构方面有丰富的经验,现负责滴滴支付中台基础工作,...
  • 什么是中台

    千次阅读 2019-10-25 12:17:40
    文章目录中台——为前台而生一、没有中台的时代——传统项目二、中台的...技术中台(3)数据中台(4)算法中台七、什么样的公司适合中台八、中台给企业带来的收益**工程方面****数据方面****创新方面**九、总结(1)...
  • 作者 | 杨威,明略科技技术中心负责人编辑 | 夕颜出品 | AI科技大本营(ID:rgznai100)本文为CSDN即将推出的《新战场:决胜中台》专刊的第 3 篇文章。【导读】数据中台...
  • 数据中台的支撑技术大致可以分为元数据管理,指标管理,模型设计,数据质量等。 首先先说说在数据中台占首要位置的元数据管理。在提到数据中台的构建,必然提到元数据,那元数据都涉及什么呢?比如,为了确保全局...
  • 基于“业务中台”构建的一些理解

    千次阅读 2019-06-27 19:59:13
    逐渐对于中台的细分又多了很多,如“技术中台”,“数据中台”,“业务中台”等等。 不论怎么细分和演变,“中台”的思路基本都是围绕“城市水电煤”的基本概念,抽象共用能力, 和SOA的架构以及微服务组件化设计...
  • 公众号回复“中台”,领取全部高清PPT文档来自公众号:CIO之家苏宁数据中台是一个大项目群:OLAP 是底层的加速、查询引擎,底层支持 Druid、ES、PGCitus ...
  • 导读:之前整理了一篇“全面解读数据中台,让企业实现数字化转型”文章,阐述了什么是数据中台、建立的原因和原则。今天让我们全面解读中台,包括企业为什么要平台化,目前中台都有哪...
  • 中移网大 全员智慧中台 部分答案

    千次阅读 2021-09-02 09:24:17
    【答案】业务中台、数据中台技术中台 【题目】破冰行动指的是通过()、组织机制破冰,打造标杆应用,健全应用战队工作模式,强化管建战协同,探索将技术中台纳入对内对外常态化生产流程 【答案】应用推广破冰...
  • 本篇主要介绍交易中台如何做到高可扩展性,通过对在线交易业务梳理分析,可以发现变化部分主要来自两个方面,一方面是交易流程的不同,如虚拟商品交易流程就非常简单,而大家电类的交易流程就比较复杂;另一方面是...
  • 在原来我谈企业中台的时候,很少专门谈到数据台和业务中台,更多谈的是技术中台和业务中台技术中台类似我们原来说的技术平台层和业务不相关。而对于业务中台,其中包括了以数据能力提供为主的微服务模块组件,也...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,095,120
精华内容 438,048
关键字:

技术中台