架构师技术领导力成长之路

今天跟大家分享一点架构师技术领导力成长的心得体会，以我在当当那几年做的事情为例，试图去总结一些普适性的方法。每个人的成长路径都不同，我能分享的只是自己的经验，没有一个通用公式能够帮助大家搞定一切问题，那样的话一切都是确定的，人生就没意思了。

什么是技术领导力

多数公司的技术体系都是团队作战，需要分工协作，无论正式还是非正式甚至是临时的领导者角色，或者只是团队中的普通一员，都需要具备与团队一同达成目标的能力，借用冯唐的书名，要有跟团队一起“成事”儿的能耐。行业里有名的亚马逊领导力准则，可作参考。

作为架构师或者架构团队，更需要具备综合的软技能，与技术团队合作，推动架构演进，支持业务发展。

 

那些年，我在当当做架构的日子

2012年我去当当做架构师，后来负责架构部，到2016年离开，4年之中做了一些事，积累了一些成果。在架构领域的总结思考，关于什么是架构什么是架构师架构师应该具备哪些能力的话题，在中国系统架构师大会上分享过，总结后发在公众号上，名为《架构师的自我修养》。今天跟大家分享的是成长过程，换一个说法叫什么呢？“那些年，我在当当做架构的日子”！

那些年都做过什么呢？挑重要的列出来：

2012年——招商平台重构

2013年——多数跨系统项目、订单重构规划

2014年——架构规划、技术栈转型

2015年——应用框架、开源组件

2016年——基础平台

 

招商平台重构

2012年6月我加入的时候，当当没有完整的系统架构信息。有多少个系统？技术团队三四百人都在做什么？各个系统是什么关系？出了问题怎么判断定位？都不清楚，只有一张很简单的架构图。刚去的时候我也一头雾水，形象的比喻就像是一朵云，在外面看是一大坨，不知道里面什么样子。幸运的是在9月份我参加了招商平台重构。这个项目希望重构第三方商家入驻卖货的系统——招商平台，与当当自营商品销售的整个流程打通结合起来。

这张图分成三个阶段来看。左边是自营电商系统阶段，比如当当最早就是卖书，后来扩充了很多品类，百货、服装、3C、孕婴童等等，还都是自营。接下来是平台并行阶段，京东也是这样演化的，不像淘宝天生就是个平台。尝试新业务模式一般是这样操作的——主营业务有一套成熟的系统，因为不知道新业务能不能做成，最好的做法是外挂一套系统。并行阶段系统前台用户端是一致的，后台所有的系统都是分开的，是两套体系。希望达到的最终目标是一个平台，右边这个图的样子，只有一套系统，像淘宝那样，自营是最大的商家，减少重复的轮子。

但这个目标没达成，我们梳理了整个流程，发现如果做成真正的平台，步子太大、伤筋动骨、成本高、难以短期见效。最终方案是把商品、库存、价格、订单等系统尽可能的结合起来，让外挂系统更轻。这个项目对我帮助非常大，完整的梳理了一遍招商平台，真正的了解了电商系统和业务流程。毕竟只作为消费者很难想象几百人搭建的电商系统的实际架构。

 

订单重构规划

其实并不存在订单重构这个项目，订单系统当时是.NET+SQLServer，迟早要重构。CTO和负责的总监发起了一个架构规划任务，如果订单系统要重构应该怎么规划，我们就去搞清楚订单系统的情况，有了一些思路，主要是通过解耦带来灵活性。正好2013年我们做了很多跨系统的项目，其中有一些与订单相关，比如说一品多促销、手机专享价、预售、预约送货、礼品包装、虚拟捆绑、就近巡仓、合约机等等，做的过程之中把对订单的想法落实了下去，使订单系统功能更强大。

右边的入驻外部平台是什么？现在当当在天猫上有旗舰店，当年在1号店也开过店，跟苏宁也谈过合作甚至都开发完了最终没上线。大家都是平台优势互补合作共赢，这种业务模式大同小异，就是作为商家入驻外部电商平台，需要同步商品信息到平台，从平台同步回来订单信息，再把物流配送信息同步过去。

架构设计需要考虑未来的可扩展性，把外部平台作为渠道，可以开多个店铺，要有相应的标识区分，这样核心功能确定了，入驻新的平台或者开新店只需要增加配置项即可实现，需要额外做的工作只是对接接口和做数据转换。作为核心系统，订单系统要具备业务扩展性，不能只靠外挂解决问题，而且要从更本质的业务模型上进行抽象，用一种扩展设计模式支持多种新的业务模式，提供可行方案令业务设想成为可能，而不是设置各种条条框框。

 

架构规划、技术栈选型

2014年初我开始负责架构部，开始扩充架构师团队，提升架构部整体能力。架构部要做架构总体规划，分为两部分，业务系统架构和技术架构。业务系统架构规划是一张蓝色的图，名副其实的蓝图，体现系统间的层次和关系，能让老板一眼看明白，不是技术层面的应用架构图。说一个“关键点”，几乎每一个框里都有4个功能模块，这正常吗？当然不正常，就是为了美观大方，所以主要是展示一个体系，一个思维模式，便于快速理解，并不是用来做系统设计。

 

技术架构图里比较特殊的是三种技术栈并存，原来的有PHP，主要是前台，有.NET，主要是后台，在12年才开始有Java。互联网电商行业主流的技术架构是什么样？技术组件平台化，用现在流行的说法叫技术中台，包括MQ、缓存、数据库、作业调度、搜索引擎、大数据体系、各种中间件。整体技术架构也用一张图展现，比较偏概念，之后根据不同的领域进行了调研和选型。画出这两张图，意味着在业务和技术两方面具备了行业视野。

 

应用框架、开源组件

经过了前面的规划和选型，我们发起了一个项目叫DDFrame，要研发一个应用框架，集成各种组件，统一技术栈、形成完整的体系，由张亮主导。其中的SOA组件选用Dubbo，然而Dubbo当时暂停更新，社区也不活跃，我们用着发现了一些问题，沈理提出我们可以自己改bug，该升级的版本升级，所以我们做了个DubboX，在功能上支持REST调用，适配当当多技术栈并存情况。因为Dubbo本来是开源的，我们反哺社区，把DubboX也开源了，解决Dubbo不更新的问题，行业里很多公司用过。做了DubboX之后我们发现做开源并不难，或者说已经有足够的能力做开源，所以就接着做了Elastic-Job，因为用阿里开源的TBSchedule也是不太爽，不如自己做一个分布式任务调度框架。不像DubboX在现成的项目上改，Elastic-Job是自己从头做，而且不涉及到数据库操作，那时候Docker也没发展起来，相对挑战难度不大。在这种情况下做了Elastic-Job之后，证明自己做一个全新的开源项目也OK，所以后来也有信心做分布式的数据库中间件Sharding-JDBC，现在张亮把这个项目做成了Apache项目ShardingSphere。当当架构部推出的开源项目在行业里产生了一定的影响力，体现了当当的技术水平，提升了技术品牌。怎么体现呢？我们招聘的时候，不会被反问你们当当的技术栈是什么样的了。

 

基础平台

到了2016年，我们开始做基础的平台。为什么做基础平台？这就说到技术体系的运转机制了。技术团队的工作，从需求提出到功能上线，再升级迭代、持续运营、到最终下线，要可控可量化可追溯，需要一整套系统，包括项目管理、自动化部署、监控告警、问题跟踪。项目管理，结合敏捷开发方法论，贯穿了需求管理、架构评审、任务看板、工时统计。自动化部署则要支持多环境的管理、发布前自动备份和恢复，以及灰度发布。上线之后，对生产环境应用进行监控，有问题需要及时报警。不管是告警还是线上问题需要跟踪处理，超时自动升级，处理完毕就要关闭。通过基础平台，我们对整个软件产品生命周期进行数据化管理，用系统化的方式支持技术团队的工作，对技术团队的整体能力提升有很大帮助。别看技术公司做产品做项目的时候提起数字化信息化产品化工程化SAAS化智能化头头是道，自己的内部管理很多还停留在基本靠人的水平，这也算是行业里一个值得玩味的小小悖论。

 

成长四要素

架构师进入新的团队，要成长，要成事儿，时间线如上所述，如果换一个视角来看这个过程，有四个要素：学习、适应、合作、驱动。这四个要素也是层层递进的关系。

第一，学习，了解业务现状，了解行业，要有行业视野，知道行业历史和发展方向；

第二，适应，融入团队，团队氛围什么样？有哪些工作流程？组织是一个什么架构？管理风格什么样？怎么做决策？

第三，合作，跟团队形成合力，产出成果，不断的沉淀一些东西出来，积累信任。

第四，驱动，需要多分享、做一些铺垫和引导，提高影响力，获得认同，形成共识，一起达成目标。

 

怎样学习？

成为一名架构师甚至是CTO是每位程序开发人员的目标，小编为你推荐几本重磅架构师书库，助你早日成为一名优秀的架构师。

 

 

《架构即未来 》

推荐理由：本书凝聚作者多年来在不同的互联网公司工作和咨询过程中积累的丰富经验，从人、过程、技术三个角度深刻而广泛地讨论了技术管理和技术架构的具体实践经验，强调了组织、人员、过程和技术的配合，深入浅出地分析了在技术管理过程中经常遇到的各种具体问题，既讲解理论，也佐以实例，让读者可以系统地获得关于技术管理和技术架构方面的知识和经验。

 

 

《架构真经》

推荐理由：本书是《架构即未来》的姊妹篇。全书共分13章，用成功互联网产品公司首席技术官和企业家的故事，引出了对构建可扩展的产品至关重要的50条规则，可帮助软件研发人员、技术运维人员和管理者修复或重新架构现有产品，了解关于扩展的佳实践并有计划地实施，还可以帮助建立一套架构原则以推动未来的研发。

 

 《系统架构》

推荐理由：首先讲解了什么是系统，什么是系统架构，并从形式和功能两个方面讲解了如何分析系统。之后开始讲解如何创建良好的系统架构。在将概念演化为架构的过程中，架构师需要对系统进行分解，以看清这些组件的结构以及它们之间的交互情况，因此需要根据一些衡量指标来构建权衡空间，以便使用优化算法找出优势较大的架构。

 

 

《架构启示录》

推荐理由：研究传统的建筑工作与数字产品的架构工作之间有着怎样的联系，探讨了4位建筑师在各自的工作中所用的技术范式，探寻这几位建筑师怎样影响数字化的世界。

你可以在阅读中思考这些工作与建筑有什么相通之处？这几位建筑师怎样运用计算机等技术来做试验，从而拓宽其工作领域？计算机、控制论以及人工智能方面的研究者与工程人员，能够通过这些建筑师与他们处理过的建筑问题，获得哪些启发？传统的建筑知识，对新兴的数字产品来说，有着什么样的意义？ 

更多精彩回顾



书讯 |华章计算机拍了拍你，并送来了8月书单（下）书讯 | 华章计算机拍了拍你，并送来了8月书单（上）上新 | 迁移学习：迈向真正的人工智能
书单 | “ABCD”,未来颇具潜力的四大信息技术方向干货 | 周志华新作《机器学习理论导引》阅读攻略收藏 | 阿里巴巴B2B电商算法首次对外公开
点击阅读全文了解更多架构好书