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

简介: 架构师技术领导力成长之路(1)

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


什么是技术领导力

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


image.png


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

 

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

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

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

2012年——招商平台重构

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

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

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

2016年——基础平台

 

招商平台重构

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


image.png


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


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

 

订单重构规划

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


image.png


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


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

 

架构规划、技术栈选型

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


image.png


image.png


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

相关文章
|
架构师 小程序
架构师技术领导力成长之路(3)
架构师技术领导力成长之路(3)
167 0
架构师技术领导力成长之路(3)
|
监控 Dubbo 架构师
架构师技术领导力成长之路(2)
架构师技术领导力成长之路(2)
138 0
架构师技术领导力成长之路(2)
|
20天前
|
运维 Kubernetes Cloud Native
云原生技术浪潮下的微服务架构演进
在数字化转型的风潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT战略的核心。本文深入探讨了微服务架构如何借助云原生环境进行优化,并分析了容器化、服务网格等技术如何助力微服务更好地适应云原生生态。通过案例分析,我们揭示了微服务在现代云平台上的实践挑战与解决策略,同时对未来的技术趋势进行了预测。
40 0
|
2天前
|
监控 负载均衡 API
从单体到微服务:架构转型之道
【8月更文挑战第17天】从单体架构到微服务架构的转型是一项复杂而系统的工程,需要综合考虑技术、团队、文化等多个方面的因素。通过合理的规划和实施策略,可以克服转型过程中的挑战,实现系统架构的升级和优化。微服务架构以其高度的模块化、可扩展性和灵活性,为业务的持续发展和创新提供了坚实的技术保障。
|
12天前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
44 6
|
9天前
|
设计模式 监控 API
探索微服务架构中的API网关模式
在微服务的宇宙里,API网关是连接星辰的桥梁。它不仅管理着服务间的通信流量,还肩负着保护、增强和监控微服务集群的重任。本文将带你走进API网关的世界,了解其如何成为微服务架构中不可或缺的一环,以及它在实际应用中扮演的角色和面临的挑战。
|
18天前
|
运维 监控 负载均衡
探索微服务架构中的API网关
在现代软件开发中,微服务架构已成为设计灵活、可扩展系统的首选方法。本文将深入探讨API网关的核心作用,包括它如何简化客户端与微服务之间的交互,提供请求路由、负载均衡、认证、限流及监控等关键功能。我们将通过实际案例分析,揭示API网关在提升系统性能、增强安全性和提高开发效率方面的重要性。
|
16天前
|
负载均衡 监控 API
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关扮演着枢纽的角色。它不仅是客户端请求的接收者,也是各个微服务间通信的协调者。本文将深入探讨API网关的设计原则、实现策略以及它在微服务生态中的重要性。我们将通过实际案例分析,了解API网关如何优化系统性能、提高安全性和简化客户端与服务的交互。
34 4
|
16天前
|
运维 监控 负载均衡
探索微服务架构中的API网关设计
在微服务架构的复杂性中,API网关作为客户端和后端服务间的桥梁,扮演着至关重要的角色。本文将深入探讨如何设计一个高效、可扩展且安全的API网关,包括处理请求转发、负载均衡、身份验证、监控与日志记录等核心功能,并讨论如何在保障性能的同时确保系统的高可用性和安全性。通过具体案例,我们将了解API网关在实际生产环境中的实现方式及其对整个微服务生态系统的影响。
38 3
|
16天前
|
Kubernetes 监控 开发者
探索后端开发的新境界:微服务架构与容器化技术
在数字化时代的浪潮中,后端开发不断演进,涌现出创新的架构与技术。本文深入探讨了微服务架构和容器化技术如何重塑后端开发,提升系统的可维护性、可扩展性和部署效率。通过实际案例分析,我们揭示了这些技术背后的原理,并提供了实施的最佳实践和面临的挑战,为后端开发者提供一条清晰的技术升级路径。
40 3