红色有角F叔对《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》的笔记(6)

企业IT架构转型之道:阿里巴巴中台战略思想与架构实战
  • 书名: 企业IT架构转型之道:阿里巴巴中台战略思想与架构实战
  • 作者: 钟华
  • 副标题: 阿里巴巴中台战略思想与架构实战
  • 页数: 357
  • 出版社: 机械工业出版社
  • 出版年: 2017-4-1
  • 阿里巴巴集团中台战略引发的思考
    但接下来的发展却事与愿违。虽然组织架构上共享业务事业部和淘宝、天猫平级,但从对业务的理解和业务贡献的体现来说,淘宝和天猫对共享业务事业部拥有更多的话语权,结果就是共享业务事业部在两大业务部门的业务需求下艰难生存着。到此,共享业务事业部的产生和发展确实与大部分人的期望有着很大的偏差。

    真正带来转折的是2010年,作为阿里电商业务的团购入口——聚划算的出现。聚划算平台刚一上线,就展现它强大的流量吸引的威力,据不完全统计,不管是淘宝还是天猫的商品,一旦进入聚划算平台,销售额会在短时间内增长25倍,聚划算对于淘宝和天猫的运营人员来说,无疑是一个增加流水的有效途径,所以一时间大家趋之若鹜,纷纷对接聚划算平台。

    这时就出现了对共享业务事业部历史转折点的一个举措,集团要求三大电商平台如果要与聚划算平台进行业务对接,必须通过共享业务事业部。
    2017-11-04 15:23:41 回应
  • 1.2 企业信息中心发展的政界
    1)重复功能建设和维护带来的重复投资。.. 单单从开发和运维两方面成本投入的考虑,对于企业来说就是一种很显性的成本投入的角度,对于企业来说就是一种很显性的成本和资源浪费。但这一点对企业带来的伤害却是最小的,只是成本的损失。
    2)打通“烟囱式”系统间交互的集成和协作成本高昂。
    3)不利于业务的沉淀和持续发展。从传统 IT 系统建设的生命周期来看,一旦系统上线以后,就进入了运维阶段。在运维阶段,也会有对系统功能完善和新业务需求的升级;因此我们看到了平均周期在几个月,甚至半年进行一次功能的升级。而事实上业务的需求时与日俱增的

    不可否认 ESB 的架构很好地屏蔽了服务接口变化给服务消费者带来的影响,是解决不同系统间实现互联互通的很好的架构,但这样的项目再企业中落地后,后面的发展就让 SOA 价值的体现出本末倒置的现象!... 企业实施 SOA 集成项目上线后,各个系统按照标准封装的这些“服务”就进入一个“稳定”状态。这里的“稳定”当然不是指服务运行的稳定,而是这些服务对外提供的功能变得“稳定”,也就是说,很多服务在初次上线后,在接下来几年的时间里就几乎没有新的服务功能的增加或提升。

    现有企业内 SOA “项目制” 建设的效果最终导致三个弊端,而其中第三个弊端“IT系统建设中实现的业务得不到沉淀和持续发展”是对企业伤害最大的。

    如果说过去,业务需求的增长态势还算比较平滑,没有体现出系统的响应能力有多大差距,那么在今天,互联网时代业务需求的增长越来越迅猛,原有系统对业务响应的能力就显得更加捉襟见肘。到了一个时间点,量变产生质变,就会出现企业核心业务系统运行多年后被推倒重来的现象。

    我承认在对业务系统的具体流程、操作、数据模型方面IT人员比业务部门更懂,因为这些系统是IT人员负责建设的,但我所说的懂业务是指,能对业务的下一步发展有着自己的理解和看法,对业务流程如何进一步优化能更好地提升业务,甚至对企业现有的业务提出创新的想法,为企业带来新的业务增长点。

    2017-11-04 15:48:37 回应
  • 2.2 服务需要不断的业务滋养
    “烟囱式”系统方式以及 SOA “项目制” 的建设方式导致了前面所说的第三个弊端:“业务得不到沉淀和持续发展”,从而造成服务不能真正成为可重用的组件,为业务的快速响应、支持业务快速创新带来的业务价值。究其原因“烟囱式”系统建设模式是导火索,ESB 在其中扮演了原本它擅长的工作,ESB也没有错。而错在SOA项目是基于一种集成项目建设的方式,就很容易造成服务提供者面对业务提出更多要求时,考核指标、工作回报都不能得到很好体现,服务提供者在主观上没有太大的积极性满足新的业务需求,再加上如果当初服务设计的功能扩展性和业务前瞻性不足,导致有心无力满足新的需求,结果是这些服务无法再进行功能扩展,成为企业“业务稳定”运行的“服务”。
    2017-11-04 15:54:54 回应
  • 2.3 共享服务体系是培育业务创新的土壤
    好的创新一定是基于企业的现状因地制宜,而这决定了在很大程度上企业的创新会来自企业内部,而且提出创新的人一定是对行业有过人的认识和理解,才有可能提出创新的想法。

    虽然现在各个行业都在进行跨界的创新,比如互联网公司去做汽车,家用电器厂商去做手机,但这样的创新存在着很多不确定的因素,其中存在的风险是一般企业所不能承受的,也非常态化的创新。对于大多数企业,眼前能做的创新还是行业内的创新,这样的创新更多情况下是依赖对企业所在行业称得上专家的人,这样的人在行业的特定领域一定有相比普通人更深的理解和认识,才能提出普通人想不到的创新。
    2017-11-04 15:58:45 回应
  • 5.2 数据库分库分表的实践
    这里给大家介绍的是在数据库层面实现异构索引的方式,也是阿里巴巴内部目前采用的方式,通过一款名为精卫填海的产品实现了数据的异构复制。本质上精卫是一个基于 MySQL 的实时数据复制框架,可以通过图形界面配置的方式就可以实现异构数据复制的需求。除了在同步异构索引数据的场景外,可以认为精卫是一个 MySQL 数据触发器+分发管道。

    大约跟 maxwell 是一回事。对shard过的库解析binlog,按另一个维度冗余索引数据+ shard。

    如果在“尽量减少事务边界”与“数据尽可能平均拆分”两个原则间发生了冲突,那么请选择“数据尽可能平均拆分”作为优先考虑原则,因为事务便捷的问题相对来说更好解决,无论是做全表扫描或做异构索引复制都是可以解决的。而写入或单机容量如果出现不均衡,那么处理起来难度就比较大。

    尽管复杂的切分规则或数据的异构索引能够给系统的性能和扩展性带来显著的收益,但其后面所带来的系统运维复杂度上升也是不能忽视的一个结果。
    如果为每一个存在跨 join 或全表的场景都采用数据异构索引的方式,整个数据库出现大量数据冗余,数据一致性的保障也会带来挑战,同时数据库间的业务逻辑关系也变得非常复杂,给数据库运维带来困难和风险,从而对数据库运维人员的要求和依赖会非常高,所以从系统风险的角度考虑,以 28 法则,在实际中,我们仅针对那些在 80% 情况下访问的那 20% 的场景进行如数据异构索引这样的处理,达到这类场景的性能最优化,而对其他 80% 偶尔出现跨库 join、全表扫描的场景,采用最为简单直接的方式往往就是最有效的手段。

    里面提的“全表扫描”其实是sql代理层给所有shard同时发query再对结果做聚合的做法。

    2017-11-04 16:20:14 回应
  • 业务中台与前端应用协作
    1. 业务中台对前端核心业务的紧密沟通机制
    各服务中心的核心架构师和运营人员会定期参与前端业务方的业务会议(比如周会)或重要项目的研讨会(比如双11大促),通过这样的方式,让业务中台对于前端重要的业务发展动向有一个准确、及时地了解
    2. 建立分歧升级机制
    出现中台与前端应用的争执时,一般按照业务负责的层级关系依次升级。... 通过这样的升级机制,将出现的分歧在更高的层面上与前端应用方达成一致。对于这样的分歧处理一般在部门层面为止,比如天猫事业部和共享业务事业部层面,不会到更高的层面,毕竟是比较具体的业务。
    3. 岗位轮转推动真正换位思考
    虽然采用业务分歧升级的机制,很大程度上解决了中台部门与前端应用方在协作过程中产生的分歧,但总体来说,因为前、中台人员所处岗位的不同,依然避免不了针对业务在哪里落地产生争执,如果遇到双方都是强势领导的时候,就会将一些本应内部通过协调沟通的问题暴露在了业务更高的层面,从而在某种程度上影响了业务中台与前端业务方的协同效率。
    所以阿里巴巴也会在一段时间内采用岗位轮换的方式,比如将业务中台某服务中心的负责人与天猫对口业务的负责人进行岗位对调,让双方在世纪工作中更真切地感知到处于不同岗位时对业务的理解和出发点。
    4. 业务持续沉淀及共建模式
    在进行业务沉淀到中台的过程中,又会出现两种情况,一是业务中台现有的人员对于要沉淀的业务功能自身就有较强的业务能力,能够很好地完成将业务功能沉淀和融入到业务中台的能力,这样一种方式是目前很多前端业务功能沉淀到中台的典型方式;另一种情况则是对于要沉淀到业务中台的业务,业务中台现有人员没有足够的业务理解和能力,此时,就会采用共建的模式,业务中台和前端应用方格子派出人员共同组建一个团队,一起负责该业务功能的实现以及到中台的能力沉淀。
    2017-11-04 16:41:43 回应

红色有角F叔的其他笔记  · · · · · ·  ( 全部654条 )

注定一战
1
美国反对美国
1
哲学·科学·常识
1
计算机组成(第 6 版)
2
图解TCP/IP(第5版)
1
沸腾十五年
2
重新理解创业
8
雄性衰落
3
股市真规则
1
资本和收入的性质
2
存在主义是一种人道主义
3
程序员的职业素养
1
何为良好生活
1
活出生命的意义
3
货币的教训
3
Docker——容器与容器云(第2版)
2
政治的人生
4
中国巨债
3
深入浅出React和Redux
5
历史的教训
4
聪明的投资者
8
Designing Data-Intensive Applications
4
投资中最简单的事
5
供给的逻辑
1
逃不开的经济周期
1
图解服务器端网络架构
1
斯坦福极简经济学
3
政治的逻辑
4
原则
5
大数据之路
1
在苍茫中传灯
4
巴菲特传(纪念版)
1
中产阶级如何保护自己的财富
1
指数基金投资指南
4
模式分类
2
深度学习
1
我看电商
2
数据挖掘导论
1
中国国家治理的制度逻辑
2
漫步华尔街
2
尽在双11:阿里巴巴技术演进与超越
2
共同基金常识
3
未来简史
2
MySQL DBA修炼之道
1
大国大城
2
计算广告
4
机器学习
1
集体智慧编程
1
重新定义公司
1
Hadoop应用架构
1
第二性
6
硅谷钢铁侠
1
大数据
5
经营的本质
1
人人都是产品经理
7
你凭什么做好互联网
4
Spark机器学习
2
聊聊架构
8
游戏引擎架构
1
美国大城市的死与生(纪念版)
5
给大家看的Photoshop讲座
1
技术的本质
5
我们房地产这些年
2
行动的勇气
2
合作的进化
5
马克斯·韦伯与德国政治:1890—1920
6
数据库索引设计与优化
1
精益企业
7
高可用MySQL
2
发布!软件的设计与部署
2
项目管理艺术
2
右派国家
5
现实感
4
领域驱动设计
11
从0到1
1
高效程序员的45个习惯
1
可扩展的艺术
3
空之境界 上
1
成为技术领导者
1
改革的逻辑
3
修改代码的艺术
9
恰如其分的软件架构
7
软件开发者路线图
3
实现领域驱动设计
1
21世纪资本论
9
持续交付
16
构建之法
6
黑格尔导论
19
极端的年代
1
微服务设计
10
Site Reliability Engineering
5
测试驱动的面向对象软件开发
3
城市的胜利
2
对知识的恐惧
5
ZeroMQ
6
现代经济学主要流派
7
数学之美
2
程序员的思维修炼
1
大教堂与集市
1
一切坚固的东西都烟消云散了
5
兜售繁荣
1
数据科学与工程技术丛书
1
政治的细节(第10版)
8
发展研究指南(第二版)
2
代码大全(第2版)
2
企业应用架构模式
9
The Datacenter as a Computer
3
无情的革命
6
新教伦理与资本主义精神
3
人类简史
7
Understanding MySQL Internals
2
他改变了中国
1
态度改变与社会影响
4
复杂
2
民主新论
19
人件
2
国家的常识
4
乌合之众
3
Web Operations
2
个人印象
4
湖上闲思录
2
自由及其背叛
7
C++语言的设计与演化
8
百年中国经济史笔记
1
改变
4
创新与企业家精神
5
Cassandra
3
不敢止步
4
意志力
2
通向财务自由之路
1
制造同意
6
美国种族简史
4
NoSQL Distilled
4
理解专业程序员
2
一个自由主义者的良知
4
政治经济学要义
2
施瓦辛格健身全书
2
房地产的繁荣与萧条
5
为学十六法
2
Akka in Action
1
Java虚拟机并发编程
3
软件工艺
3
面向模式的软件架构,卷3
1
动物精神
4
非理性繁荣
10
MongoDB权威指南
2
海量数据库解决方案
1
Erlang/OTP并发编程实战
1
学术与政治
12
Java并发编程实战
16
论中国
3
金融炼金术
4
多处理器编程的艺术
1
Effective java 中文版(第2版)
1
中國近代史(下冊)
6
系统之美
6
压力下的角逐
2
古代东方史
1
Go 语言程序设计
1
Remote
1
深入Linux内核架构
2
中國近代史(上冊)
3
隐秩序
1
空之境界(上下集合售)
1
开放社会
4
中国近代史八种
5
喀提林阴谋 朱古达战争
1
政治秩序的起源
5
现代性的后果
2
失去的胜利
9
了不起的盖茨比
5
许倬云说历史:台湾四百年
2
大规模分布式存储系统
1
C++网络编程(卷1)
2
在约定的场所
1
中国的宗教
2
了不起的盖茨比
1
希腊罗马名人传(全三册)
2
自私的基因
2
学龠
1
中国政治思想史
4
列克星敦的幽灵
1
人月神话
2
现代体系结构上的UNIX系统
1
虚拟机
2
朱熹的历史世界
1