苏宁六年技术架构的演进总结
乔新亮 InforQ


背景介绍

我是乔新亮,在苏宁负责架构管理和项目管理,还负责和云、基础平台有关的研发管理工作。上层是如何做治理,下层是如何做支撑,这其中的挑战只有自己清楚,也希望跟大家分享一下。大约2000年,我开始做和架构相关的工作,包括SOA、服务治理等。从技术的角度看,很多工作比较简单,但是在真正推进的过程中,就会知道有很多值得考虑的地方。

本文主要介绍:

  • 苏宁的转型之路;

  • 苏宁的企业架构演进;

  • 苏宁的技术路线;

  • 苏宁技术管理组织和治理;

  • 一些心得分享。

  转型之路

下面两张图可能让大家有一个印象:苏宁的业务是很复杂的。2012年,第一次接触苏宁的时候,我还在IBM工作,单纯地想苏宁不就是卖电器的吗?可能直到今天,很多人还是有这个误解。实际情况当然不是,这是非常大的误解。比如苏宁有体育版块,包括江苏足球以及今天的国际米兰。苏宁的零售是全品类经营,不只卖电器,还卖其他商品。上市的公司只是苏宁云商,苏宁没有上市的置业,包括酒店、房地产等。这么多业务都需要IT总部去支持。

接下来看看各个端。今天讲的数字化,location based service,各个端都要支持。后端这么多业务,需要组合起来,要IT去支持。这是一个Context。做技术、做架构师要有一个上下文,要考虑处理的场景是什么。以前有这么多的业态,只要处理好复杂的业务就好了。但今天开始走到了数字化,有移动端、PC、各种各样家庭互联网,流量是不可控制的。要处理的是很复杂的业务逻辑和海量交易,那么,IT怎么去支撑这些业务和交易。

做技术的人,要回答两个问题。第一个是关于价值的问题,做技术的没有直接价值,除非你对业务做了贡献,如何帮助公司的业务快速发展, 或者技术自己就是业务。第二,别跑得太快,否则结果不稳,摔倒了。大家都很关心:系统是不是宕机了?服务是不是不可用了?所以要进行平衡,如何做得既稳又快。苏宁IT有一个战略口号“稳定、安全、极致快”。任何一个应用、服务都要做到既稳定又安全又要快。这是一个理想,我们永远在为这个理想努力。

站在我的角度,考虑的是怎么能够去平衡。大家记住,架构师有一个Context,做的任何设计都不是理想的,是有上下文和限制的,在这种情况下你的架构要能支持一定程度的稳定、安全、极致快。从技术语言的角度,就是功能性和非功能性。当IT技术变成很核心的生产力的时候,这些非功能性的需求,对于系统来说就变成功能性需求。监控、可用性、可靠性等,这是功能性需求。不能说一个服务只要上线就好了。能监控吗?生产能看到吗?可用性能保证吗?有没有考虑失败的时候对业务的影响?它的可靠性怎么样?对别人服务的承诺、契约在极端的情况下会改变吗?这是苏宁,也是所有IT团队要去考虑和处理的一个问题。

  企业的架构演进

下面从业务和技术的角度,给大家分享一下这种挑战苏宁是怎么做的。我分享更多的是,在做的过程中特别困难、甚至今天都在努力克服的问题。

我原来在IBM工作,为各种各样的企业做过咨询,包括国有企业、民营企业、垄断企业、半垄断的企业、完全市场竞争化的企业。每个企业对技术的看法不一样,技术发挥的作用也是不一样的。下面让大家看一下苏宁具体怎么做。

苏宁在这几年转型过程中,技术发挥了什么样的作用?我对于技术和业务的理解是,所有的技术都是为业务服务的。苏宁在硅谷有一个研究院,刚刚过去的十月份,我去硅谷参观了Facebook、LinkedIn等企业,大概有十几天和他们深入交流,探讨了这方面的问题。我们把企业模型简化,从上到下是业务、产品、技术。下层所有的工作都是为业务做支撑。我们根据技术在里面发挥的作用来看这是一家什么样的企业。

如果一个开发人员做的东西就决定你的业务,这代表是什么?技术的使用意味着更高效、更快,更能反馈市场的变化。这种企业在市场上是极具竞争力的。所谓的工程师文化,即工程师能决定业务。像谷歌、Facebook,特别符合这种文化。第二种是产品决定业务,不是业务人员决定公司应该怎么做。像LinkedIn、中国很多的互联网公司大多都在这个位置。第三种就是业务决定。业务提要求,下面开发人员做开发。

苏宁是在逐步演变的。公司业务到底是由业务人员决定,还是产品经理决定,还是开发工程师决定?大家肯定觉得由最底层决定最好。事实上不是的。如果开发工程师根本就不思考业务,你让他决定公司的业务,那将是一场灾难。这是一个辩证的关系。我作为技术的管理者,经常会思考如何去拿捏这个度。你是希望眼睛往下面看,这是目标,并不代表公司会立刻变成这样。

我们从技术、方法论的角度来看,苏宁在思考什么。现在技术界有一句话,“架构不是设计出来的,架构是演变出来的”,我觉得太极端了。古人讲中庸之道是最好的。架构是否设计和演变,跟架构师很有关系。设计任何的架构,都会有上下文,有限制,这代表着中庸的态度,一定要适合当时场景,平衡权益。而苏宁在这个过程中,引入了企业架构,开始做规划。

这是苏宁转型过程中比较困难的一个环节。什么叫企业架构,可能很多人听到过,实际可能跟工作没有太多的关系。但是企业架构的思维方式是跟你有关的。比如,一个城市可以野蛮式生长,不用规划。中国很多城市建设就是挖了填,再挖再填,跟我们的系统建设很像。另外一种情况是,一个城市使劲做规划,根本不落地。

我毕业之后一直在北京,北京建设规划了一个又一个环,现在到七环。环状设计的确给今天北京交通带来很大的问题,但并不代表不应该做规划。很多人也知道,环的设计也给北京交通带来很大益处。那么,我的观点是,架构是边规划边演进的,然后还有做治理。这个时候就应该要考虑如何分配,谁去做规划,谁去做演进,谁去做治理。

某些企业里的治理者可能有官僚主义,这是我规划的,你就得照着我的规划做。这个时候大家会说,这种方法太差劲了,不用规划,直接做。结果各自演进,变成一种混沌状态。真正良好的过程是,要去做规划,并且要去演进。负责人,尤其是做规划、做治理的人,要有倾听机制,有服务的心态,要思考如何服务各研发团队。如果开发人员能够去思考他做的技术功能是如何支撑企业战略,如果公司每个人都思考这个问题,那么这个公司绝对很了不起。具有工程师文化的公司,对人员、工程师要求很高,从战略,到业务、应用、技术,最后到实施都管控起来,这是企业架构方法论需要处理的一个问题。

规划是做正确的事,治理是把事做正确。企业架构很关键的一点是,有一个很好的反馈机制。企业架构是回答企业的问题,产品经理应该思考这个问题,开发人员更应该思考这个问题。如果企业里每个人都在思考这个问题,并关联上自己做的事情,那这个企业会非常有活力。

苏宁企业架构怎么做的,看一下理想情况下的过程。目前的业务、技术在什么水平,我想把它演进成哪个程度、哪个水平,分析差距,找到要做的项目,然后去实施、评估,不断重复这个过程。到今天,苏宁都没有完全做到这一点,但是要不断去做,让大家做的事情匹配公司的战略。

我们看一下具体做的过程。

2011年的时候,我们意识到业务和信息战略对齐的重要性,但是大多数时候还是靠各自业务线去驱动。从2012年开始,成立了一个专门做企业架构的团队,这个团队更多做的是应用架构层面的事情。那个时候团队管控的范围还比较表面,公司内部对其重要性的认识也不是很深。那么,这个组织架构,除了有自己的规划之外,还发挥什么作用呢?当各个研发中心出现工作冲突的时候,这个决策性的组织就出现了。在苏宁常说的一句话:“找架构师来切一下,这个应该在哪里做。”出现问题,首先应该是在组织里找原因,而不是找一个人的原因。

后来,苏宁开始设计整个应用架构,包括数据资产的规划和设计。我举一个简单的例子。一组数据有很多的系统,如果大家对它理解不一致,就会带来很多问题,而这个问题是公司层面要去做治理的。直到今天,整个企业架构的治理流程和制度是比较完善的,先做规划,然后发布,最后反馈,如果在此过程当中有意见,可以不断修订。苏宁所有研发中心包括四千多人,而这个应用架构的组织不到十人,数据架构只有三四个人,但是这个组织会管控很多核心的内容和设计,同时与各个研发中心之间有匹配和对应。

从治理的结果来看苏宁的主体架构。可能很多人不了解,苏宁今天已经不是一个SAP。苏宁大概有1400多个系统,其中两个系统和历史遗留有关。一个是WCS,在2011年左右,WCS是其前台的网站,是一个套装软件。一个是SAP,和供应链管理有关。但是,到今天已经完全不一样了。

  第一代架构:POS+ERP支撑线下规模扩张

上图是第一代架构、苏宁的门店,后台是ERP,前台是POS。这个架构在当年的价值就在于,很大程度上利用它,苏宁业务超过了国美。使用这套体系能够快速开店。当时国美在收购店面的时候,苏宁是快速开店,其中一个很重要的原因是信息化的支撑。从那个时候开始,苏宁对IT的作用有了认识,吃到了甜头,几分钟快速配置系统,就能做好开店的准备工作。

  第二代架构:WCS+POS双线作战,抢滩线上

后来电子商务兴起,苏宁引进了IBM WCS电子商务套件,(上图第二代架构)这个系统支撑了苏宁好几年的发展。它非常灵活,但有一个最大的问题是,当业务量增大、业务复杂的时候,它的速度很慢,而且扩展性差。在2012年的时候,当时数据库用的是顶配的780小型机,不能支撑整体业务。2012年10月,我把这个套装软件做了拆分,可以横向扩展。可以认为是应用的一个拆分,但是应用和数据库被绑定,它的内部逻辑无法更改。把它扩展成物理部署,当时变成十倍,给苏宁留了很长的时间能够做后面系统的整个拆分和迁移,过渡阶段不让它受影响。这时候,我觉得系统的不稳定和扩展性,对苏宁的业务是有影响的。在快速支撑和发展业务的时候,如何快速横向扩展,这是很重要的一个考量点。

  第三代架构:前中后架构重塑,O2O融合

从2012年开始,苏宁一直在做的事情有两方面的原因。第一考虑的是扩展性、性能的问题。把前台网站的逻辑和后台ERP的逻辑拆到中台。苏宁有一个很简单的架构,就是前台、中台、后台,前台关注消费者,后台关注内部运营管理,中台的系统是重用的逻辑。涉及到的各端,包括PC、移动端、门店、家庭的互联网,所有逻辑调用的都是在中台系统。

第二考虑的是,如果对于今天很多新的互联网企业业务来说,可能会容易一些。但苏宁不一样,很多旧有的业务逻辑,而且体量很大、交易量很大,既要维持业务的增长,还要能调整架构调整,支持未来的增长,这本身是一个很困难的演变过程。技术永远是为业务服务的,或者说技术能够直接变成业务,这是技术团队最值得自豪的一点。

场景举例,多渠道库存共享:

  第四代架构:开放零售生态圈(未来)

到今天,苏宁有1400多个系统,服务有好几万。从2011年左右就有一个ESB,做集成,同时在那个时候,苏宁对所有的服务进行了管理。后来把它变成一个分布式的服务调用框架——RSF。一方面是服务的治理,一方面是服务的交付。

今天我关注的是,每天都会产生海量的数据,怎么样让数据发挥价值,如何让这些数据决定公司的运营。苏宁的信息技术要上一个台阶,那么苏宁的业务运营有可能是信息决定的。比如,承诺送货准时到达这个业务,如果利用技术、数据对它进行全流程、每一环节的监控,就可以做到每一单的管理。这个时候你会发现,有很多业务可能因为考虑其他的利益,去牺牲了用户的一些体验。如何让这一点变得透明化,让数据去做决定就很关键。

今天中国的电商还处在刚刚起步阶段,大部分的情况是,不知道用户的感受,如何更懂用户、更感知用户,都要靠后台海量的数据。我认为,这部分是在业务应用的层级,跟技术关系不大,更多是一种思维模式,要站在用户的角度思考。

  技术路线

下面分享一下苏宁在演变过程中的技术路线。

  电商转型初级阶段

苏宁进入电商之后,线下门店1600-1700家,有18万的用户,用的是SAP管理软件。很多企业,在今天还处在这种水平。在电商转型初级阶段,如何很快实现互联网的转型,开始引入了IBM这个伙伴,最终是要实现自我掌控。一个传统企业做转型,我觉得一定要有决心。

IBM在苏宁的顾问最多的时候有四百个,这为苏宁赢得了时间。在那个时候引入IBM WCS,以EAI方式快速接入,集成苏宁已有的信息化体系,然后基于物理机的平台,开始运转。

  电商转型自建SOA体系阶段

随着业务的快速发展,当时已经很先进的软件、平台、技术,配上最强的机器,都撑不住了,怎么办?开始拆分。在这个时候,很多是关于扩展性、吞吐量问题的处理。另外一个问题就是物理机的运维部署难以支持。后来就是把它拆分,建设了RSF、ESB框架、监控系统,引入和评估开源软件。到今天为止,苏宁新建的系统都是基于开源软件,而且都是自己掌控的。

另外,历史遗留的很有用的套装软件,也要计划迁移的。当你把系统拆分成很多服务,如果你对它不了解,那将是一个灾难。另外就是对服务的管理。ESB直到今天还在使用,因为ESB有异构的系统,比如要做中间层转换,这是ESB的作用。还有一个和这个有关的就是测试服务,服务发布时需要持续测试和集成。

  电商转型高速成长阶段

在高速成长的时候,苏宁就是在不停做拆分:

第一,要管控、规划,特别有一个团队在负责这些事情。监控体系部分,包括像基础设施的监控、Web的监控、连接的监控、服务端的监控、调用链的监控都要和管控和规划相匹配。第二,对可靠性提出了很高的要求,还对基础架构、基础组件的可用性、扩展性提出了很高的要求。

后来引入了OpenStack,苏宁现在所有的资源管理都在OpenStack上。苏宁经历过VMware、CloudStack、OpenStack阶段,管理一万多个物理机,像持续交付、持续发布目前都运行在OpenStack上。

这是电商转型高速成长阶段的技术架构现状:

  电商转型新阶段:未来

我们也在关注Docker。关于是否引用新技术,苏宁都是提前去研究,新技术是否能够更好支持业务。如果现在的技术支持得很好,我们不会轻易更换它。衡量点都在于对业务的支持和匹配。这里面最关键的是服务部分,大量系统的拆分,其实是一个治理的过程。系统再细,最后就是一个服务。关于系统的管控、服务的管控方面,RSF有一个服务管理的平台,定期出报告,负责人会收到报告,对服务进行管理和治理。

  技术管理与组织治理

管理组织有两个部门:一个是技术管理,包括CTO办公室和PMO办公室,关注标准和架构的规划,管理架构、安全、应用开发等;另一个是项目管理,包括几个人做一个项目,项目之间的承诺、契约是什么,有没有按时推进,按时交付等。管控还要有系统和工具支撑。

这里隐含了一个规则:没有数据支撑的不做管控。当系统出数据的时候,开始管控。

这里也在平衡规划管理和服务的关系,怎么把管理组织做成一个服务型组织,支持业务的发展。系统和工具是技术平台的部分。另外,所有和业务、应用没有关系的部分是技术平台,它需要支持各研发中心的发展,是不是能让别人做的更快、更稳定、更安全,是不是让别人不要去关注底层的技术细节。上面的两个组织是很小的,但发挥的作用非常大。其余大部分的组织是属于业务应用研发。

管理很重要的一点是,要看公司人的情况,技术的成熟度、能力成熟度。管理需要拿捏是业务人员驱动,还是产品人员驱动,还是开发工程师驱动。如果一个团队能力很强,为什么不能让产品驱动,不能让开发人员驱动,去决定业务怎么做呢?

  我的心得分享

第一,规划和敏捷要并重。敏捷和规划不是冲突的,应该要完美契合在一起。尤其做技术管理的,一定要时刻拿捏度,管控规划要做多大,敏捷多少要放开。

第二,人的观念转变最重要。业务产品技术的划分,最关键的还是要找到正确的人,一个好用的人抵过不好用的人10倍。

第三,要激发团队的主观能动性。规划往往会抑制团队的主动能动性,但敏捷容易制造混乱。很多人离职不是因为薪资,可能是因为成长的空间不够大,做的工作看不到价值。怎么让一个人可以拥有十年的工作经验,而不是只有一年的工作经验使用了十年,这是管理者或者技术管理者不停要思考的问题,管理者需要和团队一起成长。

最后,业务发展最重要,信息必须把要很好支持业务。

谢谢大家!

  作者介绍

  

乔新亮,拥有 15 年企业架构规划设计和系统集成的工作经历,曾任 IBM 全球咨询服务部副合伙人,也是 IBM 认证架构师和 IBM 全球技术学院成员,现担任苏宁云商 IT 总部执行总裁助理,全面负责技术管理和项目管理工作,在苏宁转型的 6 年的历程中,经历了公司从+互联网到互联网+的飞快转型及融合,同时,也亲历了苏宁技术团队从上百人到 4 千多人的急速扩张及发展,对企业架构规划、设计、系统集成领域有多年实践经验,在架构治理、组织设计方面有很深的思考和领悟,现正和研发团队一起建设高效运作研发体系,持续优化现有海量交易平台,做出有人情味、高附加值的 O2O 平台。


CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢