架构的纵坐标与横坐标，你权衡好了吗？

﹏ヽ暗。殇╰゛Y 2023-03-06 08:11 7阅读 0赞

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTI5MjE5MjE_size_16_color_FFFFFF_t_70][]

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

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

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

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

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

![640?wx\_fmt=png&wxfrom=5&wx\_lazy=1][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]

应用系统耦合结构

*  **描述特性：**
    
     *  产品业务线多
     *  产品业务共享性低
     *  产品业务之间的自定义组合要求越来越多
     *  业务特性带来的强监管（如环境、灾备、拆分等）
     *  资源快速满足业务实现，技术改造周期长，见效慢（‘污染’的速度比‘治理’的速度快）

技术团队组织结构

![640?wxfrom=5&wx\_lazy=1][640_wxfrom_5_wx_lazy_1 1]

*  **描述现状：**
    
     *  逐步推进平台化，但各团队标准与方式各有不同
     *  平台类/中间件架构需同时满足多部门、多视角的需求
     *  流程长，决策点多，节奏慢

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

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

*  对自身能力的挑战

*  对场景符合的挑战

*  对执行落地的挑战

再谈“架构规划与设计”

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

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

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

我们比较喜欢

> **案例1：**涂涂画画一黑板，指天画地一张嘴

![640?wxfrom=5&wx\_lazy=1][640_wxfrom_5_wx_lazy_1 2]

*  **喜欢的原因：**简单，方便，画一下，说一下，大家都明白了，拍个照片微信发一下，开干了
 *  **纵坐标：**（可以使用）通常的场景是，纯技术与纯技术一起的沟通，人为因素较少（比如加密方式、数据分布等），很容易达成共识，漏斗效应较少
 *  **横坐标：**（不建议使用）通常的场景是，操作/管理人与纯技术一起的沟通，人为因素较多（比如管理界面、链路监控等），表面达成共识就算过得去，漏斗效应极大

> **案例2：**你说，我做，有问题我再改

![640?wxfrom=5&wx\_lazy=1][640_wxfrom_5_wx_lazy_1 3]

*  **喜欢的原因：**你又没说，我怎么知道要做什么，先这么做做么好来，不行就改好了，万一我规划出来的东西你不要呢？
 *  **纵坐标：**（可以使用）通常的场景是，纯技术自我发起的事件较多（如扩容、降级等），不用人告诉你，系统出问题，就算你再被动，也会去解决
 *  **横坐标：**（不建议使用）通常的场景是，业务/需求/产品发起的事件较多（如界面、流程），要的不是说改就改的效率，是专业的用户视角方案，像挤牙膏这样，最后就变成一堆“补丁架构”了

我们有点反感

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

> **方式1：** 又爱又恨的 “4+1”

![640?wx\_fmt=png&wxfrom=5&wx\_lazy=1][640_wx_fmt_png_wxfrom_5_wx_lazy_1 1]

*  **反感的原因：**费时、费力、没鸟用
 *  **为什么推行？：**纵横向坚固，表达各种视角，清晰可见
 *  **为什么废弃？：**对架构师要求太高（无论是硬技能、软技能、经验等，无法推广）

> **方式2：** 完全不理解的 “DDD”

![640?wx\_fmt=png&wxfrom=5&wx\_lazy=1][640_wx_fmt_png_wxfrom_5_wx_lazy_1 2]

> **方式3：** 浪费时间的 “详细设计”

![640?wx\_fmt=png&wxfrom=5&wx\_lazy=1][640_wx_fmt_png_wxfrom_5_wx_lazy_1 3]

*  **反感的原因：**见鬼去吧，没那么多时间，又要快又要详细，你觉得可能吗？
 *  **为什么推行？ ：**别的不说，在做之前，难道不该想的很清楚吗？拿着清晰地设计与需求交流难道不对吗？
 *  **为什么废弃？ ：**你觉得在没做之前就想的很清楚，现实吗

现在我们是这么干的

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

经过一年的不断尝试，直到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 4]

![640?wx\_fmt=png&wxfrom=5&wx\_lazy=1][640_wx_fmt_png_wxfrom_5_wx_lazy_1 5]

> **上线阶段：**基于WIKI给出

*  架构全景图（概要）
 *  架构技术栈
 *  开发者指南
 *  管理者指南
 *  环境搭建指南

![640?wxfrom=5&wx\_lazy=1][640_wxfrom_5_wx_lazy_1 4]

![640?wx\_fmt=png&wxfrom=5&wx\_lazy=1][640_wx_fmt_png_wxfrom_5_wx_lazy_1 6]

结束语

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

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

我想，这才应该是我们学习的方法吧（全文完）

[Link 1]: http://mp.weixin.qq.com/s?__biz=MzIzODQ3NDQ4Mw==&mid=2247483717&idx=1&sn=ff1538a978f33c260ea83340b7333504&chksm=e93984d9de4e0dcf1fca189ec91c64d95561e9b978403ff803fe4de4e9f7024f4e0bfbfd6e9c&scene=21#wechat_redirect
[Link 2]: https://blog.csdn.net/u012921921/article/details/107830713
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTI5MjE5MjE_size_16_color_FFFFFF_t_70]: /images/20230208/982d33c4312e46e78bd37322e2f1afaa.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1]: /images/20230208/4ca0987208f4458d87c0e424b819d8a1.png
[640_wxfrom_5_wx_lazy_1]: /images/20230208/0d4f5210fdc54bc0b9e061b89b006592.png
[640_wxfrom_5_wx_lazy_1 1]: /images/20230208/5145856438d94f08bf5dd24578f4daf1.png
[640_wxfrom_5_wx_lazy_1 2]: /images/20230208/fcc89a08ace842978760727b7b2edb84.png
[640_wxfrom_5_wx_lazy_1 3]: /images/20230208/445c94b8ff3a4468addfb413149f2b95.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 1]: /images/20230208/4abcf8929b5a4a79a402bdfc625e0748.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 2]: /images/20230208/efe07bf293f14800b83823dfd7442451.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 3]: /images/20230208/d397a515a5644cc5916aff4aa4ad2543.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 4]: /images/20230208/eaa58fe015fe48fa8c5f4c92b1162cbe.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 5]: /images/20230208/84c3367905654d2899427ec6e9ecdbd1.png
[640_wxfrom_5_wx_lazy_1 4]: /images/20230208/23768a00c3f74381b16b7bb63d4056ff.png
[640_wx_fmt_png_wxfrom_5_wx_lazy_1 6]: /images/20230208/c5174c2a388c4d5281cbeb6647cca791.png