精华内容
下载资源
问答
  • 企业IT架构转型之道:阿里巴巴中台战略思想与架构实战.pdf
  • 企业 IT 架构转型之道 阿里巴巴中台战略思想与架构实战
                   

    内容简介

    本书从阿里巴巴启动中台战略说起,详细阐述共享服务体系如何给企业的业务发展提供了支持。介绍阿里巴巴在建设共享服务体系时如何进行技术框架选择,构建了哪些重要的技术平台等,此外,还介绍了组织架构和体制如何更好地支持共享服务体系的持续发展。

    主要内容分为三大部分:

    • 第一部分介绍阿里巴巴集团中台战略引起的思考,以及构建业务中台的基础——共享服务体系。
    • 第二部分详细介绍共享服务体系搭建的过程、技术选择、组织架构等,如分布式服务框架的选择、共享服务中心建设原则、数据拆分实现数据库能力线性扩展、异步化与缓存原则、打造数字化运营能力的方案、平台稳定性能力的开发、共享服务中心对内和对外的开放共享等。
    • 第三部分结合两个典型案例,介绍共享服务体系项目落地的过程,以及传统企业进行互联网转型过程中的实践经验。

    编辑推荐

    本书从10年前阿里巴巴为何要启动中台战略说起,详细讲述了惊心动魄的架构转型过程,以及在这个过程中的深度思考和各种实践,包括成功经验,也包括失败教训。

    这是迄今为止首次披露阿里巴巴集团中间件体系最全面系统的资料,这些宝贵资料对所有进行“互联网+”实践的企业和单位都有参考价值,对软件开发人员和架构师也会有所启发。

    作者简介

    钟华(花名:古谦),阿里巴巴中间件首席架构师,15年中间件领域行业经验。对传统企业 IT 建设和互联网架构都有较为深入的理解,有着扎实的理论基础和丰富的实战经验,多次作为总架构师协助大型传统企业打造业务中台项目,为企业实现“互联网+”转型提供了科学的发展方向和强有力的技术支持,项目涉及政府、制造业、金融、交通、媒体等多个领域。

    本书内容

    序言一

    本书讲述了阿里巴巴的技术发展史,同时也是一部互联网技术架构的实践与发展史。

    为一个复杂的、高速发展的业务构建一个技术系统是一个巨大的挑战。阿里巴巴集团主要是以电子商务、支付为业务主体,这类系统都是复杂的商业系统。这个业务又承载于互联网之上,互联网又具有海量的访问请求与数据。这两者的结合,形成了阿里巴巴集团的业务系统的关键特点。

    不同于搜索、社交之类的应用系统,电子商务、支付的业务特性决定了其必须有很高的稳定性与可靠性。用户在使用搜索引擎的时候,哪怕丢失了一半的搜索结果,用户可能都没有觉察。但在电子商应用中,每一笔订单、每一个状态、每一次支付都不能有丝毫差错。与此同时,像双十一这种业务高峰时刻,每秒钟就需要处理十万笔以上的订单。高可用、海量、复杂的业务逻辑交织在一起,是阿里巴巴业务系统的主要挑战。

    阿里巴巴集团为了应对这些挑战,在技术上、组织架构上都进行了广泛的实践。并进一步将此种实践提升至中台这样的概念。

    阿里巴巴集团在很多技术方面进行了不断的探索,如数据库的水平扩展、复杂业务系统的结构化与服务化、大型系统的消息处理、关键业务系统的实时调控等。在数据库层面,阿里巴巴很早就启动了去 IOE 的项目,本质上是想解决大规模数据的线性可扩展问题,包括存储与访问两个方面。为了实现这个目标,发展了一系列的中间件来支撑这种新的架构。

    随着业务的发展,阿里巴巴也面临着复杂业务系统的解耦问题。在互联网行业,需求的迭代速度非常快,通常每周都会有数十个功能更新或增加,并要及时发布。如何保持业务相对隔离可以让工程师大规模并行工作,传统上有很多解决方案,如 SOA、ESB 等,但如何在解耦的同时仍能满足互联网海量访问且具有高性能的要求,阿里巴巴集团对传统技术进行了革新,提出了一系列实用的技术方案。

    系统规模进一步变大之后,需要解决更多、更复杂的问题,比如在全球进行分布式的部署、99.999%以上的高可用、容灾等,这对系统的架构与设计提出了更多的挑战。

    解决了系统的静态架构之外,很快就会发现,像此类复杂的企业级互联网应用需要在运行时可以全程进行动态感知与管理,不仅要有全部的监控能力,更要根据业务流量进行业务的优雅降级,确保系统高可用等。

    我认为本书将阿里巴巴一系列在工程上的实践进行了系统的总结,也为进一步的系统演进积累了很好的经验,打下了坚实的基础。

     

    阿里巴巴集团 CTO 张建锋(行癫)

     

    2017年4月于杭州

    序言二

    阿里巴巴电商系统的架构经历了烟囱式架构到分布式架构再到共享式架构的转变,在这个过程中持续推动着大量业务的创新,天猫、聚划算、闲鱼、拍卖、玩兔、淘抢购等应用不断涌现出来,有成功也有失败,因为架构无法决定市场的成功还是失败,但是作为土壤可以不断孵化新的物种。阿里巴巴从2008年开始的架构优化过程其实并没有解决该做什么的问题,但是解决了创新效率的问题。当有人告诉你做一个市场需要100人年的时候,你会犹豫,到底投还是不投;如果告诉你100人月的时候,你会毫不犹豫地投入,所以这时候一个优秀的架构已经超出了效率本身的范畴,而是决定企业成败的关键因素。

    我的感受是,最大的浪费不是重复建设,而是不断重复建设。在早期往往一个新业务的上线除了数据可以被重复使用之外,服务却不能被重复使用。其实服务的重用将比数据重用带来更多好处,数据只是原始生产资料,服务则包含逻辑,是工厂的加工车间,如果加工过程也一样可以复制,将带来生产效率的大幅度提升。

    系统的建设要从生产型模型升级到运营型模型,从版本模型升级到迭代模型。运营型模型最大的优势是所有的积累都被沉淀,而生产型模型会因为10%的差异而重新建设100%的系统。每次都是新的故事、新的逻辑、新的代码,而这些都来自几个人的脑子。运营型模型的逻辑则来自于无数客户、供应商、工程师的的脑子,并经过不断的积累,那么差距就显而易见。

    本书主要介绍了阿里巴巴电商系统架构的演变历史,对各个行业在做企业 IT 架构优化会有很大的帮助。

     

    阿里巴巴集团中间件技术部研究员蒋江伟(小邪)

     

    2017年3月于杭州

    前言

    在过去15年的 IT 从业经历中,有很长一段时间我都是以软件服务商的身份参与了企业的 IT 系统建设,对于过去十几年来企业IT的发展有一定的认知和理解,带着对互联网技术的憧憬来到阿里巴巴中间件研发团队,有幸能近距离了解阿里巴巴的业务架构发展模式和业界顶尖的互联网技术。这种略显特殊的工作经历,使我对阿里巴巴的共享服务理念和企业级互联网架构很快能了然于胸,当我把这些内容介绍给越来越多的企业客户时,听到最多的反馈词语就是“启发”。

    这让我逐渐意识到,在当今整个中国社会都处于互联网转型的浪潮中,不管是政府职能单位、业务规模庞大的央企,还是面临最激烈竞争的零售行业都处于一个重要的转折点,这个转折对企业业务模式带来了冲击,当然也给企业的信息中心部门带来了挑战:如何构建 IT 系统架构更好地满足互联网时代下企业业务发展的需要。阿里巴巴的共享服务理念以及企业级互联网架构建设的思路,给这些企业带来了不少新的思路,这也是我最终决定写这本书的最主要原因。

    本书从阿里巴巴启动中台战略说起,详细阐述了共享服务理念给企业业务发展带来的业务价值。接着会分享阿里巴巴在建设共享服务体系时如何进行技术框架的选择,哪些重要的技术平台支撑起了共享服务体系,这也是迄今为止对阿里巴巴集团中间件体系对外最全面系统的介绍。除了技术层面之外,本书还分享了阿里巴巴内部的一些经验和实践,如组织的架构和体制如何更好地支持共享服务体系的持续发展。

    最后结合两个典型案例来介绍如何在实际工作中应用共享服务体系。一个案例是国内某大型国企进行互联网转型的尝试和探索,最终走上成功转型之道的过程;另一个案例是国内某零售企业如何基于阿里巴巴提供的企业级互联网架构重构企业 IT 架构,在短期内快速重构供应链、SCRM 等平台,打造了企业全渠道分销平台,为该企业在竞争最为激烈的零售行业构建了差异化的竞争优势。希望通过这两个案例使读者更真切地看到共享服务体系项目落地的过程,以及它在企业互联网业务和 IT 架构转型过程中所起到的重要作用。

    我一直以来都信奉再好的技术和框架如果不给企业带来业务价值,就没有太大意义,所以本书更多是从技术架构解决了什么问题,企业收获了哪些业务价值的角度进行说明和阐述,并没有描述太多晦涩的理论、算法和模型。“他山之石,可以攻玉”,希望更多的企业 IT 管理者、架构师、立志成为架构师的技术人员能从这本书中获取有价值的信息,进而对自身职业发展和所在企业业务发展有所帮助。对于有一定技术背景,希望对互联网架构有一个整体了解的读者,本书也是一本不错的入门书籍。

    最后感谢在本书写作过程中给予我无私帮助的同事和朋友:蒋江伟、赵杰辉、周磊、赵勇、司徒放、程正君、赵林,黄杰龙等,没有你们的帮助,就不会有本书的出版。

     

    钟华

     

    2016年12月

    第一部分 引子
     

    本章从阿里巴巴为何启动中台战略说起,谈到阿里巴巴共享业务事业部从建立、摸索及系列演变,到最终成为阿里巴巴业务中台战略中核心组成部分的过程。深入分析阿里巴巴共享业务事业部发展历程中所遇到的一系列问题和困境,而这些问题也恰恰是当今很多传统企业信息系统建设过程中所遇到的问题,找出这些问题的症结是根治这些问题的必修课。

    2015年年底,当大多数企业忙着进行年度工作总结和下一年规划时,阿里巴巴集团对外宣布全面启动阿里巴巴集团2018年中台战略,构建符合 DT 时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制,即作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场,而中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务形成强力支撑。

    与任何公司一样,阿里巴巴组织架构的战略调整势必对公司现有组织架构、部门间的协作等各方面都将带来深远影响。战略执行到位、3年内达到战略调整所设定目标,对业务的创新和支持将带来巨大的影响,假若没能很好地控制战略执行过程中带来的风险,对组织架构的动荡过大,都会给现有业务带来不小的影响。

    阿里巴巴为什么会在这样一个时间点做出如此重大的决定呢?这还要从一次商务拜访说起。在2015年年中,马云带领阿里巴巴集团的高管,拜访了位于芬兰赫尔辛基的移动游戏公司 Supercell,这家号称是世界上最成功的移动游戏公司,以《部落战争》《海岛奇兵》《卡通农场》等游戏知名。Supercell 是一家典型的以小团队模式进行游戏开发的公司,一般来说两个员工,或者5个员工,最多不超过7个员工组成独立的开发团队,称之为 Cell(细胞),这也是公司名字 Supercell(超级细胞)的由来。团队自己决定做什么样的产品,然后最快的时间推出产品的公测版,看看游戏是否受用户欢迎。如果用户不欢迎,迅速放弃这个产品,再进行新的尝试,期间几乎没有管理角色的介入。团队研发的产品失败后,不但不会受到惩罚,甚至会举办庆祝仪式,以庆祝他们从失败中学到了东西。使用这样的模式使得 Supercell 公司成为了年税前利润15亿美元的游戏公司,2015年 App 畅销排行榜上 Top 10的游戏中,Supercell 公司开发的游戏占据了榜单的大半江山。在笔者撰写此书时,2016年6月,中国腾讯公司以86亿美元收购了员工数不超过200人的 Supercell 公司84.3%的股权,每一名员工人均贡献的估值超过3.54亿人民币。

    笔者对 Supercell 模式的理解是这家游戏公司经过6年的时间将游戏开发过程中公共、通用的游戏开发素材、算法做了很好的沉淀,企业的文化充分鼓励员工进行创新,甚至进行试错,才使得他们在开发的众多游戏中以最快时间找到那些用户真正喜爱的游戏。这种强大的业务试错能力是 Supercell 相比于其他游戏公司最大的差别,也是最核心的竞争力。其他的游戏公司难道没有想到学习这样的模式吗?答案一定是肯定的。为什么其他游戏公司不具备 Supercell 这样的能力呢,我觉得很多人忽略了 Supercell 所构建的“中台”能力,抛开个人水平高低的影响,Supercell 公司在多年的游戏研发中积累了非常科学的研发方法和体系,使得今天公司可以支持几个人的小团队在几周时间就能研发出一款新游戏,并进行公测。

    Supercell 的模式给参加此次拜访的阿里高管们很大的震撼,在大家反复的心得交流和讨论中,一个非常重要的问题引起了很多人的反思:信息时代的公司架构到底应该是怎样的?正是有了这次拜访才真正让阿里巴巴的领导层有了足够的决心要将组织架构进行调整,在此次拜访的半年后,集团正式启动2018年中台战略。

    所谓的“中台”,并不是阿里巴巴首先提出的词语,从字面意思上理解,中台是居于前台和后台之间。其实在阿里巴巴集团启动中台战略之前,有另一个被很多外界所熟知的“厚平台,薄应用”架构,说起这个架构则不得不说其中最为重要的一个部门——共享业务事业部,这个部门的产生、演变和发展在笔者看来都极具代表性和参考价值。

    第1章 阿里巴巴集团中台战略引发的思考
    第2章 构建业务中台的基础——共享服务体系
    第二部分 共享服务体系搭建
    第3章 分布式服务框架的选择
    第4章 共享服务中心建设原则
    第5章 数据拆分实现数据库能力线性扩展
    第6章 异步化与缓存原则
    第7章 打造数字化运营能力
    第8章 打造平台稳定性能力
    第9章 共享服务中心对内和对外的协作共享
    第三部分 阿里巴巴能力输出与案例
    第10章 大型央企互联网转型
    第11章 时尚行业品牌公司互联网转型

    阅读全文: http://gitbook.cn/gitchat/geekbook/5bc579a542d7d32f50f16d75

               

    再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

    展开全文
  • 此文是我阅读《企业IT架构转型之道》一书的学习笔记的上半部分,所有内容出自钟华老师的这本书。零、为何阅读《企业IT架构转型之道》 在加入X公司后,开始了微服务架构的实践...
        

    640?wx_fmt=gif

    此文是我阅读《企业IT架构转型之道》一书的学习笔记的上半部分,所有内容出自钟华老师的这本书。

    零、为何阅读《企业IT架构转型之道》

      在加入X公司后,开始了微服务架构的实践,也开始了共享平台服务的建设,在这方面阿里巴巴的中台战略是一个较好的参考。于是,领导就赠了这么一本《企业IT架构转型之道》给我,希望我学以致用,更多的是有这样的一个眼界去指导我们的中台架构设计。因此,我花了两周时间快速地阅读了一下此书,总结了此文作为学习笔记以供日后复习用。此书的确讲了一些干货,虽然很多内容留于表面,但是对于中台的定义和思考,建设中台的方法以及阿里中间件有比较完整的描述,和多年前出版的《淘宝技术这十年》以及《大型网站技术架构-核心原理与案例分析》一样,是一本值得学习的好书。

    一、引子

    Part 1 阿里中台战略引发的思考

    • 起源自2008年阿里巴巴三大电商体系的技术支持架构

      • 1688、淘宝、天猫三套电商体系架构完全独立

      • 三座烟囱分别矗立支撑阿里巴巴最核心的电商业务

    • 烟囱式系统建设系统对企业的“三大”弊端

      • 重复功能建设和维护带来的重复投资

      • 打通“烟囱式”系统间交互的集成和协作成本高昂

      • 不利于业务的沉淀和持续发展 => 对企业伤害最大

    • 企业信息中心的组织职能是业务支持?

      • 问题核心在于IT信息部门在现有模式下大多被高管定位为业务支持的部门 => 一个花钱的成本中心

      • 问题原因在于IT信息部门的人员不懂业务 => 这里的懂业务是指“能对业务的下一步发展有着自己的理解和看法,对业务流程如何进一步优化能更好的地提升业务,甚至对企业现有的业务提出创新的想法,为企业带来新的业务增长点。”

      • 问题结果导致了IT信息部门的人员很少能在一个业务领域做足够的业务沉淀 => 对业务知其然而不知其所以然

    640?wx_fmt=jpeg

    “烟囱式”的系统建设模式

    Part 2 构建业务中台的基础—共享服务体系

    • SOA架构的核心价值

      • 服务重用 => 从服务重用到共享服务

    • 共享服务体系的建设:克服“烟囱式”架构的三大弊端

      • 避免重复功能建设和维护带来的成本浪费 => 没有实现系统业务互通的诉求

      • 最大程度避免打通不同系统间实现业务交互带来的集成和协作成本 => 各个应用在核心业务层已经实现了统一和畅通

      • 能够很好地培养出特定领域的专家 => “既精通业务,又熟悉技术”的复合型人才

    • 企业信息中心组织阵型的调整

      • 针对共享服务体系重新组织人员,使成员有机会成为业务领域的专家(复合型人才)

      • 最核心的角色是架构师,他们会是各服务中心的业务负责人

      • 信息团队会从“业务支持”的组织职能转向基于企业核心业务和数据进行运营的团队

    640?wx_fmt=jpeg

    阿里巴巴的“大中台”体系建设

           在阅读这一部分时,个人最大的感触就在于企业信息中心的境遇,我所在的公司是一个传统行业,我们部门是从2018年末开始扩建的信息中心,和广大企业信息中心一样,虽然无一不被认可信息部门对企业发展的重要地位,行政级别也和核心业务部门的级别相当,但是实际情况却是没有同样平等的话语权,因为在高层领导的眼里就只是单纯把信息中心定位为了业务支持部门,是一个花钱的成本中心。而造成这样处境的原因,也很赞同钟华老师在书中的观点,那就是信息部门的员工不懂业务,这里的不懂业务是指能对业务的下一步发展有着自己的理解和看法,对业务流程如何进一步优化能更好的地提升业务,甚至对企业现有的业务提出创新的想法,为企业带来新的业务增长点。而要提高信息部门的员工对于业务的精进,需要建设类似阿里巴巴的共享服务中心,服务需要不断的业务滋养才能足够强大地支持前线的士兵,也只有在滋养中才能从最初提供单薄业务功能的服务组件成长为企业最为宝贵的IT资产。

    正如钟华老师所示,未来在整个社会进入开放共享的时代,企业最大的价值将会是基于核心业务和数据进行对外开放的运营,到那时信息部门的共享服务体系将成为企业最为宝贵的资产。

    二、共享服务体系的搭建

    Part 3 分布式服务框架的选择

    • “中心化”与“去中心化”服务框架的对比

      • 服务调用方式的不同带来业务的响应和扩展成本:基于ESB的响应速度慢(因为网络开销大一倍),而要扩展ESB需要承担软硬件的不小投入(比如巨大的授权费)

      • 雪崩”效应束缚了“中心化”服务框架的扩展能力:不适合互联网企业的根本原因,因为一旦雪崩故障恢复的时间和成本都非常高昂!

    • 阿里巴巴的分布式服务框架HSF

      • 组成部分:服务提供者、服务调用者、地址服务器(Nginx)、配置服务器(服务注册&发现)、Diamond服务器(类似于Zookeeper)

      • 工作原理:服务节点对配置服务器列表的获取、服务的注册发布、服务的订阅、服务规则的推送(如果需要)、服务交互

      • 核心能力:Netty+Hession数据序列化协议实现服务交互(大并发量下的高性能)、容错机制(长连接+秒级感知)、线性扩展(增加服务实例即可扩展服务能力)

    • 关于微服务

      • 微服务化的应用架构的有效服务管控?

      • 分布式事务的难题?

      • 自动化运维和平台稳定性?

      • 微服务的服务设计?=> DDD

      • 传统SOA架构基于“中心化”的ESB构建,而微服务采用的是系统提供服务的方式实现系统间的互通;

      • 传统SOA实施的方式是项目制,而微服务是以做产品的方式让服务在业务发展过程中快速演化;

      • 阿里巴巴2009年开始的共享服务体系算得上是微服务实践的先驱

      • 从本质上说,微服务是SOA的一种演变后的形态,与SOA的方法和原则没有本质上的差别

      • 微服务与SOA的两点最鲜明差异在于:

        • 传统SOA架构基于“中心化”的ESB构建,而微服务采用的是系统提供服务的方式实现系统间的互通;

        • 传统SOA实施的方式是项目制,而微服务是以做产品的方式让服务在业务发展过程中快速演化;

      • 概念一时爽,问题一堆堆:

        • 微服务化的应用架构的有效服务管控?

        • 分布式事务的难题?

        • 自动化运维和平台稳定性?

        • 微服务的服务设计?=> DDD

    微服务不是“免费的午餐”,阿里巴巴2009年开始的共享服务体系建设历程算得上是微服务架构的建设过程。正如钟华老师所说,“罗马不是一天建成的”,企业如果要构建微服务架构体系,也是需要多一份耐心的,通过服务能力在业务发展过程中的不断沉淀,当业务的能力沉淀到一个阶段后,才能真正感受到微服务架构给企业的业务发展带来的长远价值。

    Part 4 共享服务中心建设原则

    • 服务中心的三个特征

      • 服务中心是伴随业务不断发展的:不做过于超前的设计,也不做过于理想化的架构

      • 服务中心的服务形态多样化:接口、工具、数据...

      • 一个服务中心还可以进一步划分:单个服务模块、多个服务模块...

    • 服务中心的划分原则

      • 高内聚、低耦合原则

      • 数据完整性原则:特别强调大数据思维

      • 业务可运营性原则:服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元

      • 渐进性的建设原则:小步快跑,服务化从简单开始!

      • 设计 => 遵循面向对象的分析和设计方法论

      • 运营 => 服务中心应该是一个完整额业务模型

      • 工程 => 综合评估业务层对服务中心在DB、业务以及运营方面的需求和技术上需要的投入

      • 更多靠的是架构设计经验总结,很难给出精确的量化指标

      • 一般来说会兼顾3个方面的需求:

      • 实际中的一些基本原则:

    记得张逸老师在《领域驱动战略设计实践》课程中的开篇提到他向DDD大师Eric Evans提问“如何正确地识别限界上下文?”,结果Eric Evans思考了一会儿,严肃地回答了一句:“By experience!”。这是一个正确的废话,但好像又蛮有道理。对于共享服务中心的建设和划分来说,也同样如此,更多的是依靠架构设计经验的总结,作者也很难给出一些具体问题给出一个精确的量化指标。正如作者所说,架构本来就是一个追求平衡的艺术,不仅是设计原则上的平衡,还要在技术、成本、资源、性能、团队等各方面进行平衡,以最高效地解决主要问题。

    640?wx_fmt=png

    Part 5 数据拆分实现数据库能力线性扩展

    • 数据库分库分表的实践

      • 阿里巴巴分布式数据层平台发展演变:Cobar(2006) => TDDL(2008) => DRDS(2014),更多阿里中间件的简介可以转向这里:http://jm.taobao.org/about/

      • 数据尽可能平均拆分:需要结合业务数据的结构和业务场景来决定

      • 尽量减少事务边界:“事务边界”指单个SQL语句在后端数据库上同时执行的数量

      • 异构索引表尽量降低全表扫描频率:“拿空间换时间”,阿里巴巴的精卫填海产品

      • 将多条件频繁查询引入搜索引擎平台:采用专业搜索引擎平台提供搜索服务,Lucene、Solr、ElasticSearch

      • 简单就是美:“数据尽可能平均拆分”作为第一优先考虑,82法则

    我们都有一个印象就是在数据库开发和调用时,要充分利用索引,避免全表扫描。但是,作者说到在真实的业务场景中很难完全避免全表扫描,比如对于订单进行复杂的分布式条件检索的时候,就会需要采用全表扫描,将查询语句同时推送到后端的数据库中才能实现该场景。但是,因为调用量不会很频繁,而且计算的数据量并不大,所以整体上不会给DB产生太大的影响。另外一个点就是,从系统风险的角度来看,以82法则,在实际中,作者建议仅对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理,达到这类场景的性能最优化,而对于其他80%偶尔出现跨库join、全表扫描的场景,采取最为简单直接的方式往往就是最有效的方式。

    640?wx_fmt=jpeg


    展开全文
  • 大数据大创新-阿里巴巴云上数据中台之道、企业IT架构转型之道 阿里巴巴中台战略思想与架构实战的电子书,主要介绍中台相关的概念及实践。
  • 企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》读后感 转至简书:读《阿里巴巴中台战略》-思企业IT架构之转型 2015年阿里巴巴集团启动了中台战略,目标是要构建符合互联网大数据时代的,具有创新性、灵活性...

    《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》读后感

    转至简书:读《阿里巴巴中台战略》-思企业IT架构之转型
    2015年阿里巴巴集团启动了中台战略,目标是要构建符合互联网大数据时代的,具有创新性、灵活性的“大中台、小前台”的机制,即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场,而中台将集合整个集团的运营数据能力,产品技术能力,对各前台业务形成强有力的支撑。

    那阿里集团为什么要建立一个“大中台、小前台”的架构呢?我们从阿里共享业务事业部的发展史说起。起初,阿里只有一个淘宝事业部,后来成立了天猫事业部,此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系,两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因,阿里集团又成立了共享业务事业部,其成员主要来自之前的淘宝技术团队,同时将两套电商业务做了梳理和沉淀,将两个平台中公共的、通用的业务功能沉淀到共享事业部,避免重复建设和维护。后来上线的聚划算、1688、菜鸟物流等业务,均是基于这个“大中台,小前台”思路建设的。如下图所示:
    在这里插入图片描述
    前文说到的烟囱式的系统架构,相信IT行业的朋友们都有过亲身经历。我们来总结一下这个模式的弊端主要有哪些:

    1. 重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力,财力,更重要的是时间!在目前高速发展的互联网市场大环境下,商机是稍纵即逝的。

    2. 打通烟囱式系统间交互的集成和协作成本高昂。各大企业不得不借助ESB产品,构建企业服务总线,打通各系统间的交互问题。当然,我们并非是要完全否定ESB系统,它的确是能在某种程度上实现系统间的互联互通,但这种“中心化”的服务架构缺点也有不少。“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点,而这个中心点的能力是很难进行扩展的;也许有人会说我可以通过增加中心服务总线实例的节点数量,以达到线性的扩展平台能力。但这种做法其实过于理想化了,我来举个例子,说明一下这种模式的“雪崩”隐患。假设企业的服务总线集群数量是10台,每个负载量是80%。当访问峰值来临时,有可能因为某一个应用的不规范调用或者某个服务提供者出现了异常,导致了其中1台“罢工”。此时,服务路由压力就落在了剩下9台上,每台的平均负载量就变成了88%(个别服务器会更高),出现问题的概率就增加了。此时假设又有一台不堪重负也“罢工”了,就会出现后面的8台服务器在访问峰值时会瞬间被访问洪流冲垮,这就是“雪崩效应”。(想起了原先公司经常出现的大面积死机白屏…)

    3. 不利于业务沉淀和持续发展。很多企业经常上演这样的一幕:一个系统上线运行5、6年后,原先的系统升级改造已经不能满足当下的业务发展诉求,需要整体升级,而这样的升级往往意味着对原有系统推到重建,之前多年的业务服务能力没有多少被沉淀下来,造成巨大的资产流失。

    那“大中台,小前台”的共享服务体系到底有什么优点呢?说到这,我先来给大家举个例子吧。

    大家都知道特种部队在现代战争中是个狠角色,特种部队强大的战斗力绝不仅仅是因为他们当中每个人都身体健壮、思维敏捷、百发百中,而是因为他们拥有一群强大的后盾来支持他们。特种部队虽然人数不多,但可以调动鹰眼、武装直升机、无人机、轰炸机、火箭、导弹、甚至是航空母舰。这就是为什么他们十几人可以打败对方几百人上千人的原因。还有个简单例子,一架飞机在天上飞行,通常机舱内只有1-2名飞行员,当飞机出现故障时,仅靠飞行员自己是无法快速、准确的定位问题、解决问题的。而地面指挥中心是有非常多的专家工程师,他们可以快速的帮助飞行员定位问题,并提出解决问题的方法。上述两个例子就是“大中台,小前台”的典型应用,其中的“大中台”就是把所有与势能相关的公线资源全部收纳,组成一个“火力中枢”。

    我总结共享服务平台体系的优点主要有如下几点:

    1. 服务可重用。通过松耦合的服务带来业务的复用,不必为不同的前端业务开发各自对应的相同或者类似的服务。例如淘宝和天猫不必各自开都开发一个评价服务。

    2. 服务被滋养。作者在书中提出了一个观点:服务最不需要“稳定”。一个服务如果一味追求不变,那就是固步自封,就会逼着其他系统去建同样的“轮子”。服务需要被滋养,不停的滋养,只有滋养才能最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产,而服务所需的滋养正是来自新的业务不断的接入。

    3. 服务助创新。大家都知道创新不是一件容易的事情,因为有些本质上的创新按照传统的开发模式是需要从分析、设计、开发,每一个环节都从0开始的,这样一来就会导致投入成本大,开发周期长,可能等你开发完了,商机已经被别人抢占了,公司领导可能考虑到上述因素就把你这个想法PASS掉了。而共享服务平台中的诸多服务是经过清晰的沉淀,可以通过重新编排、组合,快速的响应市场,达成创新,武侠小说里不常说天下武功,唯快不破嘛。

    4. 服务敢试错。说到试错,其实试错和创新有着千丝万缕的关系,有时甚至可以划等号,部分试错是会变成创新的。共享服务平台由于具备快速编排、组合服务的能力,可以以较小的成本投入来构建出一个新的前端业务,即使失败了,公司损失也很小。这在传统模式构建的系统中是几乎不可能达成的。

    5. 服务造BD。如今BIG DATE(大数据)成为近年来互联网和IT行业最为炙手可热的名词,很多企业甚至将互联网转型的期望完全寄托到大数据上,企业纷纷上马大数据项目。但多数项目在落地实施时却很难,主要有两个问题:一是数据分布广、数据模型和标准不统一。需要进行数据层的打通、权限的控制、格式的转换、以及数据的清洗和转换等一系列复杂的工作;二是缺少“数据科学家”。也就是说人件,项目只有强大的软件和硬件支持是远远不够的。更重要的是要有能基于对业务的理解提出对大数据平台需求的专家。此类专家需要懂数据采集、懂数学算法、懂分析、懂预测、懂市场应用…这样的专家对任何企业来说都是难寻的,就算你的公司财大气粗,可以把某某公司的专家挖过来,但他来到另外一个行业,另外一个公司,遇见另外一个全新的系统,由于对你公司的业务和技术熟悉程度较低,还是很难短时间带来效益。而共享服务体系能很好的帮助企业培育出懂业务的专家,这些人员在自身拥有不错的技术功底的前提下,加上对业务熟悉度的不断提升,使之才有希望成为能发挥大数据平台价值的“数据科学专家”。

    结合当前我部门主营的客服系统,我觉得我们完全是可以借鉴这种中台战略思想来规划和建设我们的新一代系统的。

    首先把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。例如我们从外呼业务中梳理出工单管理和问卷管理的能力;从知识库中梳理出知识搜索的能力;从85电商平台中梳理出商品销售和库存管理的能力等等。然后将重复、类似的服务进行整合,同时在单个服务的完善和增强的过程中注意服务的通用性,避免其他相似“双胞胎”服务的出现。由于服务能力的集中管控,很大程度会促进我们一体化运维的能力,但在“大中台、小前台”的模式下,每一个服务都负责对N多个前端业务应用提供支持,这就要求运维在信息安全、备份、监控等方面要有更强的能力。

    展开全文
  • 这段时间有幸读了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》这本书,受益匪浅,本书是从阿里巴巴启动中台战略说起,详细阐述了共享服务体系如何给企业的业务发展提供支持,介绍了阿里巴巴在建设共享...

    这段时间有幸读了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》这本书,受益匪浅,本书是从阿里巴巴启动中台战略说起,详细阐述了共享服务体系如何给企业的业务发展提供支持,介绍了阿里巴巴在建设共享服务体系时如何进行技术框架选择,构建了哪些重要的技术平台等。

    记得刚刚拿到这本书时,自我感觉此书食之无味,但当我将第一章内容读完时,激起了我读下去的欲望,本书主要内容分为三大部分,第一部分介绍的是阿里巴巴集团中台战略引起的思考,以及构建服务中台的基础即共享服务体系。

    首先,大家应该都知道前台跟后台,所谓的中台,并不是阿里巴巴首先提出的词语,从字面理解来看中台是居于前台和后台之间,其实在阿里巴巴集团启动中台战略之前,就有另一个被外界所熟知的“厚平台,薄应用”架构,阿里巴巴是在2015年启动的中台战略,我佩服的是阿里巴巴的战略眼光,阿里早在2009年就开始建设共享事物事业部,几年的经验沉淀积累为启动中台战略的转型打下了坚实的业务基础,说了这么多,那么什么是中台呢,中台系统作为支撑和链接的作用,链接了前台与后台,支撑后台技术提升,为生产、商品营销指明方向有着重要作用。

    我们知道。2008年淘宝技术团队同时支持着淘宝和天猫两大电商平台,1999年成立的B2B电商平台1688也一直拥有自己的技术支持团队,总体来讲也就是三套电商体系架构完全独立各自应用独立开发和运维,在电商平台上有购物经历的人都知道,一个标准的电商平台至少提供了会员服务、商品的信息、交易支付,不管是B2B、C2C、或者B2C的电商平台都需要提供,为什么阿里的三大电商平台会独立建设和维护,而这就是所谓的“烟囱式”系统建设模式,不仅仅是阿里,或许很多企业IT系统的建设模式都是如此,当一线业务部门提出需求,到需求分析开发测试上线的过程中,每次的需求变更修改都预示着一座新的烟囱矗立而成,作为后台开发人员,我对此深有体会,当我们收到一个新的服务需求变更时,我们内心是拒绝的,但是客户的需求是第一位,最终我们还是要改的,因为受限于之前服务设计的通用性和业务前瞻性不足,要满足新的业务需求就要在原有的数据模型和业务逻辑上作较大的改动,这是后台开发最不想做的,实际情况中可能更多的人会在改动带来的风险和满足新业务需求的选择中,选择放弃对新业务需求的支持,保持现有服务提供的稳定,重新开发一套跟这个服务差不多的功能模块,最终的结果就导致又一个新的烟囱形成。最终这样建立起来的系统就能发现大量的功能和业务在多个系统中同时存在,在日新月异的互联网时代,如何更好的整合内部资源、更好的提升用户体验,实现各个系统间的交互成为必然发生的事情。

    想到我们PMS-T系统,我们也一直在避免这种烟囱式的建设模式,避免代码的重复,但是我想系统中还是会存在一些这种烟囱式的结构吧,毕竟系统的每个模块的开发都十分仓促,从开始到现在,有多少人接手了这个系统的开发和设计,每个人的代码风格以及设计思路开发都不会相同,因为最初对系统的不熟悉,只能按照设计来实现功能,功能实现起来或许简单,但是如果考虑到全局这个功能是否还是会这样设计呢?是否能跟现有的东西进行融合呢?鉴于这个系统一直在不停地修改,前人不断的挖坑,现职的人只能埋坑,其实也不能怪前人的代码有问题,因为当时的需求可能就是如此,也不用考虑太多东西,也可能只是在当时的系统全局的需求下就是如此,后来随着工程不断地增加、业务的复杂程度也不断的增强,然后就暴露出之前存在的很多问题,以及表设计和业务逻辑都要有较大的改动,正如书中所言,一个系统上线运行5~8年后,企业的信息中心会像企业更高领导人提出随着业务的快速发展,现有的系统不管是技术架构还是业务模型都不能满足现在业务发展的需求,需要整体系统的升级,而这样的升级往往意味着对原有的系统推倒重建。


    如图1-1所示。到了一个时间点,量变产生质变,就会出现企业核心业务系统运行多年后被推倒重来的现象。

    展开全文
  • 1.SOA 面向服务 服务之间的松耦合 2.优点:单点:“雪崩”导致瓶颈 SOA:熔断,重试 挑战:如何保证高可用性、稳定性 高可用性:集群 3.阶段 服务化----->平台化阶段------->...垂直...
  • 本书从阿里巴巴启动中台战略说起,详细阐述共享服务体系如何给企业的业务发展提供了支持。介绍阿里巴巴在建设共享服务体系时如何进行技术框架选择,构建了哪些重要的技术平台等,此外,还介绍了组织架构和体制如何更...
  • 企业IT架构转型之道》随笔之SOA、ESB、微服务、API网关(2019-08-07)名词注释为什么会进化展望 作者在本章中提到的“烟筒式”系统建设模式,在目前大部分公司起步的时候都会出现。目前笔者已经经历了三家公司,...
  • 粗略翻了一遍CTO推荐的这本书,发现它的内容正好可以填补这些不足,它从架构演进历程的视角整体梳理了阿里巴巴曾经踩过的坑,挖出的宝。准备弄个小系列,品读思考一下这本书。这里先挖个小坑,看看多长时间能填平… ...
  • 企业IT架构转型之道 - 读书笔记

    千次阅读 2017-11-18 21:43:41
    2015年阿里巴巴集团启动了中台战略,目标是要构建符合...那阿里集团为什么要建立一个“大中台、小前台”的架构呢?我们从阿里共享业务事业部的发展史说起。起初,阿里只有一个淘宝事业部,后来成立了天猫事业部,此...
  • 虽然Google Blockly最初只是一个用于低龄儿童学习编程的图形化编程语言,但是可能是由于它的架构本身比较利于扩展和二次开发;因此可以方便的定义“programming”意外领域的规则范式。除了TLog中使用的面向日志分析...
  • 评:推荐做系统架构师的同学可以看一下。的确讲了一些干货,但很多内容留于表面。对于中台的定义和思考,建设中台的方法以及阿里中间件有比较完整的描述。阿里巴巴电商系统的架构经历了烟囱式架构到分布式架构再到...
  • 原书扫描版本,非手机截图。完整,带书签。 阿里巴巴启动中台战略的原因,及架构演变... 本书从10年前阿里巴巴为何要启动中台战略说起,详细讲述了惊心动魄的架构转型过程,以及在这个过程中的深度思考和各种实...
  • 工程层面:基于分布式架构的共享服务架构,解决了大规模应用的问题,也引入了分布式事务、问题排查等挑战 不能图一时快把业务拆的太碎,到最后不得不用很大资源投入来解决技术上面对的问题 二、原则 高...
  • 读书笔记:《企业IT架构转型之道

    千次阅读 2019-01-19 22:02:51
    传统的项目制外包开发方式,造成IT部门的成员在业务上并没有非常深入的积累沉淀,更多的是知其然而不知其所以然,没有培养出这样的人才,这对企业未来的发展是不利的。   第2章:构建业务中台的基础-共享服务...
  • 〇、背景: 各种秒杀大促 ...应用架构 数据容灾 …… 阿里的技术创新和成果 针对方面 工具或方法 限流和降级 TMD(Taobao Missile Defense) / http_sysguard / Sentinel 流量调度 ...
  • 一、思考1、厚平台、薄...3、业务架构师:(服务中心业务负责人) 从技术开发初试,在多年业务领域的需求浸染中,不断形成对该业务全面的知识体系以及自身的理解,对该业务在集团中的职能定位、市场发展趋势都有一定的
  • 1 出发点:企业IT系统建设普遍面临的问题和处境  很多企业面临的问题和处境: 1.1 『烟囱式』系统建设模式。 当业务部门提出业务需求,信息中心部门进行系统集成商的招投标,再进入到需求收集、需求分析、开发、...
  • 三、共享服务中心架构 四、数据库瓶颈解决方案 1、读写分离 2、水平分区 3、TDDL 4、DRDS 五、数据库分库分表实践 一、中心化服务框架 二、阿里巴巴分布式微服务框架HSF 工作原理如图3-5所示 三、...
  • 对传统企业IT建设和互联网架构都有较为深入的理解,有着扎实的理论基础和丰富的实战经验,多次作为总架构师协助大型传统企业打造业务中台项目,为企业实现“互联网+”转型提供了科学的发展方向和强有力的技术支持,...
  • 阿里巴巴中间件首席架构师 钟华(花名:古谦)在2017杭州云栖大会中做了题为《企业IT架构转型之道》的分享,就企业建设中台的价值是什么,业务中台与数据中台共同构建起企业中台架构,阿里在中台建设中提供哪些服务做...
  • 企业架构可以分为两大部分:业务架构和IT架构,大部分企业架构方法都是从IT架构发展而来的。 业务架构:是把企业的业务战略转化为日常运作的渠道,业务战略决定业务架构,它包括业务的运营模式、流程体系、组织结构...
  • 企业IT架构—共享服务体系

    千次阅读 2019-03-29 14:23:06
    最近阅读了《企业IT架构转型之道》,感触较大,和我们公司这几年遇到的问题有很多相似之处,如果能够早几年看到这本书,一定能少走很多弯路,下面说说我对共享服务体系的感受。 先介绍一下这...
  • 在中国银行业,工商银行的信息化建设一直走在前列。1999年,正是工商银行率先在国内...下面,让我们来看看,工商银行的新IT架构究竟有哪些不同处?1、IT架构改变,来源于银行压力越来越大一是,客户群体多样化增...
  • 企业微服务架构转型-关键诉求

    千次阅读 2018-08-13 14:58:00
    对于企业从传统IT架构到微服务架构的转型,绝对不是盲目的跟风互联网企业,而是企业的业务规范,企业的信息化水平和IT成熟度发展到一定阶段后的比如诉求,那么这些关键的诉求究竟有哪些? 从系统规划建设期到IT...
  • 传统企业IT架构如何能更好的支撑企业互联网业务的转型 发布时间:2017-05-09 15:33:08521人关注8人参与 阿里巴巴董事局主席马云在2016年11月16号在乌镇召开的第三届世界互联网大会开幕式上发表演讲时提出了...
  • 今天主要是谈谈企业架构如何助力IT组织的转型。 一句话概括:企业架构IT组织的转型是非常有价值的。 背景我的架构治理工作始于2012年:2012.01~2013.12 重点是IT架构能力建设问题 2014.01~2017.10 重点是...
  • 面向微服务的企业云计算架构转型

    千次阅读 2016-08-22 14:55:21
    云计算的本质是提高效率,而不是降低成本,公有云就是要提高社会的效率,私有云就是要提高 IT 的效率。从这个角度看,实施云计算就是做精益运营,而微服务架构为精益运营提供了架构上的保证,因为微服务是小的、容易...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,760
精华内容 11,504
关键字:

企业it架构转型之道