架构的纵坐标与横坐标,你权衡好了吗?-阿里云开发者社区

开发者社区> 中生代技术> 正文
登录阅读全文

架构的纵坐标与横坐标,你权衡好了吗?

简介:
640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。2011 年在大智慧担任测试负责人期间,针对互联网产品技术核心和重点,DevOps 的倡导者与实践者,曾建立大智慧数据平台“云测试平台”。2013 年加入好买财富,参与了整个公司应用和技术架构变迁,参与很多和系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。

业余时间喜欢运动、户外与画画,也维护了一个知乎专栏“草根罗汉的修行之路(kiddwyl)”,欢迎关注。



在旧文《把越来越多的服务治理好才是当务之急,服务微不微可以慢慢来》的结束语中,我有提到“对于好买来说,今年应该是推行‘平台化’以来的第2个年头,有时抬头看看,会觉得很累,路途漫漫,可当你回头看看走过的路,将会觉得成就满满”。

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

在这2年里,虽然实现的平台时长有这样那样的问题暴露,但总体上来讲,特别是用户操作、用户体验上还是比较有特点的

一说起 “架构”,相信很多小伙伴的脑海中都会浮现出“海量高并发”、“大促场景”、“容器化”等牛X的词语,有时在架构师的面试中,也会被问及“你们这多少台服务器”、“每秒TPS多少”、“容器化做了吗” 这样的问题。

的确,这些很重要,也充分体现了“没这点量,你还搞什么架构”的观念,可是在某些业务场景与技术策略面前,单单考虑架构纵向深度是不够的,我们还需要充分满足架构横向广度的实现


名词解释:架构的纵坐标与横坐标


首先,先用一张图来解释下“啥叫架构的纵坐标与横坐标?”

640?wx_fmt=png&wxfrom=5&wx_lazy=1


通过图中罗列的内容,相信大家已经看出,在我的理解中,所谓 架构的纵坐标 与 架构的横坐标 各代表了什么。


聊一些我们的现状


在描述现状之前,先来讲一个段子:

  • 段子背景:某技术聚会,谈论到某某公司在实施集成测试环境中mock方案时,研发与测试之间产生了互相推诿的现象,最终导致效率低下的事件

  • 其中某一段堆话:

    • ...... ......

    • A君:“怎么会有这样的事?他们老大是干嘛吃的,怎么不出来说话?”

    • B君:“出来说了呀,研发老大与测试老大的意见还不统一呢?”

    • A君:“研发老大?测试老大?你们还是按测试与运维来划分组织结构的?”

    • B君:“嗯,是啊。。。”

    • A君:“晕死。。你们居然还没有F-Team啊!?这怎么玩啊”

    • B君:“说来话长啦。。至少现在还没有,打算逐步逐步调整。”

    • A君:“这有啥逐步的,就你们老大一句话的事,说调不就调啦,我觉得就是你们老大怕担风险,不作为!”

    • B君:“...... ......

    • ...... ......


段子听完了,这位B君同学说的似乎很有道理,可我们是否可以这么设想一下

  • 假如他们系统的耦合度很高呢?

  • 假如他们业务部门不同意呢?

  • 假如他们目前找不到既懂业务而且还能Hold技术的F-Team老大呢?

  • 假如他们当前不打算重构系统呢?

  • 假如...... ......


道理人人都懂,记得之前在大智慧时期,听到过这么一段话 你绝对不是第一个看到问题的人,也绝不是第一个提出这样方案的人,为什么一直没解决呢?总有原因的,有时缺的不是方法,而是时机


好了,为了表达清晰,做了一些现状的铺垫,现在我就从 应用系统耦合结构 与 技术团队组织结构 这2个维度来说明

应用系统耦合结构

640?wxfrom=5&wx_lazy=1

  • 描述特性:

    • 产品业务线多

    • 产品业务共享性低

    • 产品业务之间的自定义组合要求越来越多

    • 业务特性带来的强监管(如环境、灾备、拆分等)

    • 资源快速满足业务实现,技术改造周期长,见效慢(‘污染’的速度比‘治理’的速度快)

技术团队组织结构

640?wxfrom=5&wx_lazy=1

  • 描述现状:

    • 逐步推进平台化,但各团队标准与方式各有不同

    • 平台类/中间件架构需同时满足多部门、多视角的需求

    • 流程长,决策点多,节奏慢

‘横向’架构对架构师带来的挑战

请容许我再一次把 架构 与 架构师 等同起来,立足在架构师的视角,从3个维度出发,来谈谈‘横向架构对架构师带来的挑战’


  • 对自身能力的挑战


  • 对场景符合的挑战


  • 对执行落地的挑战

再谈“架构规划与设计”

架构,是一个比较抽象的词语,架构师,却是一个实打实的“第一人称”


既然称为 “师”,那就有个性,有理想,有情感,有倾向性... ...再加上硬技能的不同,不同团队在“架构的纵坐标与横坐标”之间的权衡将通过架构规划、架构设计等方式表达出来


基于以上说明,下面我将从3个方面来描述下我们在“架构的纵坐标与横坐标”之间的权衡中的问题与经历 

我们比较喜欢



案例1:涂涂画画一黑板,指天画地一张嘴

640?wxfrom=5&wx_lazy=1

  • 喜欢的原因:简单,方便,画一下,说一下,大家都明白了,拍个照片微信发一下,开干了

  • 纵坐标:(可以使用)通常的场景是,纯技术与纯技术一起的沟通,人为因素较少(比如加密方式、数据分布等),很容易达成共识,漏斗效应较少

  • 横坐标:(不建议使用)通常的场景是,操作/管理人与纯技术一起的沟通,人为因素较多(比如管理界面、链路监控等),表面达成共识就算过得去,漏斗效应极大


案例2:你说,我做,有问题我再改

640?wxfrom=5&wx_lazy=1

  • 喜欢的原因:你又没说,我怎么知道要做什么,先这么做做么好来,不行就改好了,万一我规划出来的东西你不要呢?

  • 纵坐标:(可以使用)通常的场景是,纯技术自我发起的事件较多(如扩容、降级等),不用人告诉你,系统出问题,就算你再被动,也会去解决

  • 横坐标:(不建议使用)通常的场景是,业务/需求/产品发起的事件较多(如界面、流程),要的不是说改就改的效率,是专业的用户视角方案,像挤牙膏这样,最后就变成一堆“补丁架构”了

我们有点反感

如上所说,对于 架构的横坐标 我们也推行过一些方法,但都不长久


方式1: 又爱又恨的 “4+1”

640?wx_fmt=png&wxfrom=5&wx_lazy=1

  • 反感的原因:费时、费力、没鸟用

  • 为什么推行?:纵横向坚固,表达各种视角,清晰可见

  • 为什么废弃?:对架构师要求太高(无论是硬技能、软技能、经验等,无法推广)


方式2: 完全不理解的 “DDD”

640?wx_fmt=png&wxfrom=5&wx_lazy=1

  • 反感的原因:费时、费力、没鸟用

  • 为什么推行?:纵横向坚固,表达各种视角,清晰可见

  • 为什么废弃?:对架构师要求太高(无论是硬技能、软技能、经验等,无法推广)


方式3: 浪费时间的 “详细设计”

640?wx_fmt=png&wxfrom=5&wx_lazy=1

  • 反感的原因:见鬼去吧,没那么多时间,又要快又要详细,你觉得可能吗?

  • 为什么推行? :别的不说,在做之前,难道不该想的很清楚吗?拿着清晰地设计与需求交流难道不对吗?

  • 为什么废弃? :你觉得在没做之前就想的很清楚,现实吗

现在我们是这么干的

说实话,在上面一系列想法 ‘失败’ 后,平台类/中间件类的架构,在“横坐标”上让我失去平衡,没有了着力点


经过一年的不断尝试,直到17年1季度,基本在平台类/中间件类架构的“横坐标”上摸索出了一些门道:


设计阶段:按模板输出PPT

  • 故事开始:

    • Why - 痛点与现状

    • How - 怎么做才能解决?

  • 故事经过:

    • Who - 谁用?谁能获得利益?

    • User - 有哪些用户视角的突破或改变?(含应用运维、系统运维、管理员、应用接入等)

      • 当前:使用前(或前版本)的顺序图

      • 改变:使用本版本后的顺序图

      • 未来:最终希望达到的顺序图

  • 故事结尾:

    • Cost - 几个人(人/天)?多少资源(如服务器)?

    • When - 什么时候上?


640?wx_fmt=png&wxfrom=5&wx_lazy=1

640?wx_fmt=png&wxfrom=5&wx_lazy=1


上线阶段:基于WIKI给出

  • 架构全景图(概要)

  • 架构技术栈

  • 开发者指南

  • 管理者指南

  • 环境搭建指南


640?wxfrom=5&wx_lazy=1

640?wx_fmt=png&wxfrom=5&wx_lazy=1

结束语

这篇文章写得有点长,看到这里您辛苦了,用简短的话结束吧


每家公司,每个团队,每位架构师,都有着不同的情怀与特点,所谓 “条条大道通罗马” ,在发展的过程中切记不应该照搬别人的经历,我们要做的,应该是把这些经历当成故事来看,并在相似的经历篇章中灵活借鉴


我想,这才应该是我们学习的方法吧(全文完)


来源:中生代技术

原文链接

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
官网链接