我真的只是标题党:以架构的思维看世界

简介: 本文来自中生代技术交流群,作者是阿里段子手-半兽人药剂师,掌声!!!哈哈。本文值得各位架构攻城狮们一看,精彩不容错过。提前声明,我们真的是标题党哟。

为什么要聊聊架构?

又到一年财年底,又到了各架构师们交配、no,交流的季节。各位蠢蠢欲动,开始为新年的规划发展开始忙活。最近一段时间,本人也连续给多个新系统做了技术架构,也看了很多别人做的架构、老系统演进架构。


随着经历和经验的不断增加,貌似在画图工程师这条路上也有了一定的进步,跨入了画图高级工程师的行列。结合“知行合一”的战略指导方针,在“格物致知”到一定程度后,也尝试通过自己的知识迁移能力、抽象总结能力,来寻找画图这件事里蕴含的“道”。So,写一篇总结、软文、段子、睡前读物,来尝试“融汇贯通”一下这条修仙路上的体验。

在这里,不得不首先提到好友“云召”最近总结的名言,他高度概括了我们是在什么样的背景下开展画图工作的:


这一趴一定要头狼all in 996进来,解决当前的痛点,赋能上游业务,以众筹作为抓手,反哺团队全栈能力,整点干货,这样某领导的才能buy in

在这种背景下,产品化、一站式、赋能、中台能力都成为了高频词,我们的架构能够适应这些变化吗?


应该能帮你突破思维障碍的“通用架构思维”

在以“格物致知”为执行策略,“架构思维”为总体指导方针下,我们尝试对某一问题域进行不断的深入研究。

架构思维,作为一种帮我们全局理解问题、条理性梳理解决方案的方法论,TA会在产品能力、特性、边界、服务模型、运营模式等纬度进行高度抽象和整合。而其本身也是可以再进行抽象的,貌似当无法上手思考如何架构一个事情的时候,会有这样一套 “架构模板”,指导我们逐步上手,并结合我们的领域知识逐步深化。

下面尝试阐述一下这种思维方式。

1.小而美的问题驱动

无论是域架构、业务架构、系统技术架构,很大程度上都是问题驱动式的,通过问题直接找准解法,在很多人看来,这已经是最后一步了。为对应的问题找出解法,这难道不就是解决方案吗?剩下的就只要找一些码农来写代码就行了啊,还有什么要做的?
然而,结合前面所述的中台建设、产品化等要求,万里长征只开始了第一步。
下面我们从一个看似简单的问题域开始,以通用架构思维,搭建解决方案:
识别一句话中的错别字

凭感觉,应该是分词、监督学习等领域的内容。一来容易想不清楚,先在架构图里面随便画一块儿下来:


好,看起来完全看不懂,也不具备对代码结构进行指导的能力。程序猿不可能看着这个名词,就开始哼哧哼哧的all in并996了。

于是继续思考,要支撑错别字识别这个核心能力,我们的业务领域需要具备些什么?首先我们可能要想到的是“分词”,然后要想到的是基于分词后的一种监督学习形“纠错”,这种纠错方式我们暂时考虑用类似“规则”的方式进行管理。


按照一般的领域能力建设来说,下面的基础越牢固,支撑的能力越多,上面的场景才能得到扩展。于是我们从“中文语法语意”出发,衍生出了一些句法相关的能力。例如一句话中的禁忌词识别、一句话中的死链接识别、一句话中的二义性识别、一句话中的知识点冗余或缺失等。


同时,由于互联网时代造新词能力的空前强大,我们考虑到,一个词语是否为错别字、禁忌词,很可能会因为在不同的场景下产生变化。所以我们考虑用“词库”的形式对各个“规则”进行管理。从业务逻辑上区分“金融词库”、“服务规范词库”等集合。然后TA变成了这样:


随着领域模型的扩展,核心能力也产生了演进,技术架构的边界也开始扩大,系统承担的责任也开始扩大了。


通过架构能力,抽象整合服务能力、扩大业务边界,在很多大公司里是非常重要的事情,这几乎可以关乎一个团队的生死存亡。


想大做小跑得快不再是一句鸡汤,为什么想大是放在跑得快前面?从前是说,落后就要挨打,我们要跑得快点;现在是地盘小就被蚕食,我们要多圈一些地。而通过深化领域模型,驱动核心能力扩展,这是让系统能够承担更多业务的一项好方法。


核心能力的地盘目前看起来划得差不多了,我们已经问题域从“解决错别字”提升到了“解决中文文本词法质量、句法质量”的高度了,结合团队现有的几颗人的能力来看,貌似也能小步跑起来了。系统使命暂时扩到这儿吧。

2.服务渠道,能力输出

下面继续思考文章开头提到的,怎么“赋能”,这是一个很实际的问题,也是产品化比较重要的一步。这里我们要整体性的考虑很多东西,后端世界的各种分布式、高并发、高可用等各种点子喷薄而出,各种名词、砖头都想要往架构图上去堆了。作为各位的梦想导师,此时需要提醒大家的是,越是到这种感觉“呼之欲出”的时候,越需要谋而后动,国足都能做到90分钟而不射,我们也要克制所谓的“条件反射式画图”的冲动。
在考虑赋能的时候,我们通常反问自己三个问题:
  1. 提供什么样的服务方式?
  2. 如何解决服务性能问题?
  3. 为哪些人提供服务?
在服务方式这里,这里也有模式可循,稍微套一下,看能否套上:  
  1. 统一实时服务  
  2. 分布式实时服务   
  3. 嵌入式组件化   
  4. T+1服务   
  5. 调式服务
于是我们的架构再次长出一块儿服务渠道层:


基于已有的各种服务模式,我们考虑性能上的东西,这里需要画的是系统级的技术架构,可用于指导代码分层落地的,像“分布式计算”等名词级别的东西,就不太适合放到架构图里面了。像“多线程”等程序设计级的东西,我们也不适合放这里。那放些什么呢?因为蚂蚁所有的系统上线就是支持多机器无限扩容的,而DB是较难扩容的;所以我们在程序设计上,会更多的考虑用相对富裕的资源来做事情。


针对统一服务和分布式服务的特性,系统架构统一考虑搞一层缓存来提升服务体验,减少对数据库的压力。在核心领域模型或者数据模型里面的东西,都会被缓存下来,为核心能力中的计算逻辑提供基础:

到目前看起来,核心能力、领域能力、服务渠道、服务容错都具备了,貌似可以开始写代码了吧?按照bundle来分,也已经有好多要写了啊~我还以为就1个人就能搞定呢,现在看起来,光是后端都得多来几个人建设,领域能力也得招几个做算法的同学来一起搞了吧。

3.管理、运维与多租户赋能

别急,从产品化的角度上看,上面的梳理还只是完成了一半。想想“云召”在开篇时候说的那句话吧,在赋能的时候,多租户、产品化、云是多么的重要啊。我们怎么吧这些能力赋给更多的租户呢?

从通用架构思维上讲,我们会尝试拉一块儿管理模块出来,就像这样:


然后,我们就要站在租户角度去思考,如何完成所谓的“一站式管理”、“一站式运营”了。
站到这个层面,我们顺理成章的又要考虑几个问题了:
-如何让租户方便的“入驻”?
   -系统如何管理各租户的模型?
   -租户如何管理他的团队?
   -租户如何管理功能?
   -租户如何运营功能?

  嗯,有问题都好办,我们直接把疑问句转成陈述句,就可以写进去了:


貌似看起来还挺不错的啊,这图画完,拿出去给团队讨论也能有讨论基础了。


在考虑多租户的时候,我们其实已经从“系统承载的业务功能”,进入了“系统承载的运营功能”领域了。在右侧的管理板块中,我们已经考虑了“功能运营”是需要建设的,这个时候再回到核心领域模型,我们发现单纯的通过系统本身,把词库做“领域分类”已经是无法满足“多租户”的诉求了。


我们知道,无论词法识别、句法识别、词语纠错、句法冗余识别,都是需要通过大量语料做模型训练的,而模型的适用范围恰好是语料训练的范围。


而在可见的未来,随着不同租户的入住,个性化需求会带来语料域的扩展与冲突。采用平台本身来维护语料、模型,是无法把领域精度做到机制的。而且对于租户来说,他们也无法自己进行调优。


于是,我们还会像所有的架构一样,尝试加一个数据层,作为领域模型的“生产者”。但这里和其他的架构又不一样了,我们不会这样:


因为写这些毫无卵用,我也建议各位在以后不管各种架构图中,都不要在这一层把“存储选型”写上来。对于指导程序猿工作毫无用处,交流架构的时候你也会完全忽略这一层。


我们是这样写的,让模型训练能够开放给多租户,并且能够满足“一站式”的特性。这样,我们专门规划了一层来作为领域模型的生产者:


4.外部依赖与系统边界

看起来好像已经把事情讲得很清楚了,然而还有另外一块儿,那就是外部依赖。在SOA化的架构下,每一个业务系统都不是独立存在的,TA要和自己所处业务域的其他系统打交道,要和一些基础功能系统打交道。这些可以直接使用别的系统已有的服务能力。在这上面,我们比较重要的是需要考虑对外部依赖的SLA评估。


根据已有的架构,我们再演进一块儿外部依赖,如下:


对外部依赖的梳理,便于我们在做架构的时候,深入思考方案的可行性、技术选型、域架构合理性等更多的问题。这一部分有助于在整个SOA体系下,具备更全局的架构视角。


有关域架构的设计、画图、边界裁定等心得体会,会在后续的文章中进行分享。

3.设定技术目标

最后,结合业务目标,再定几个技术目标,貌似就成型了。技术目标作为程序猿在系统建设过程中的实际挑战,也能加强程序猿在挑战问题过程对技术架构的持续优化和演进。


在大图的建设上,再通过颜色区分已建能力和待建能力,就让架构师也具备了一些PM的职责。而在这张大图的建设上,程序猿也会根据实际编码过程中的问题,促进架构演进。


除此之外,架构师也还兼顾着一些远期规划的职责:

  •     这个盘子有多大?能发展几年?
  •     领域深度够深吗?具备核心能力吗?
  •     这个方向能指导我们团队扩大到什么规模?
  •     这种建设能力可以冲出公司,走向世界吗?

上面那种架构图,除了对模块、代码层级具备指导意义,TA还能对产品形态具备一定的指导性,架构从此也能影响人机交互,例如我们的门户建设:


找一种思维方式看世界

所以,我其实也是标题党。
进来的架构师,或者立志走在架构师路上的同学可能看完后会这样问:
这个和我们平时看的技术架构、业务架构都不一样啊
你是不是把业务架构和技术架构搞混到一起了啊,nope

遇到过不少朋友,对名词定义的准确性有着苛刻的要求;给我的感觉像在写八股文,技术架构只能写xxx,业务架构只能写xxx,并以此为荣。


架构存在的作用,在这里也不进行定义和描述,因为一样会有同学来和我争论定义的准确性。
那么本文其实想表达一种思维方式,当你面对问题难以下手时候,不妨尝试这套武功秘籍,换个角度看世界。

总结

从一个小而核心的问题开始,找出解决方案,作为核心能力输出。
思考支撑这种核心能力输出的领域模型。通过领域深度不断的扩展系统可承载的业务边界(再次强调,这点很重要)。并扩展能够输出的核心能力。
以产品化的视角,考虑扩展服务的方式、渠道,让系统更灵活,能够适应更多的用户。
考虑服务性能、体验,设计好本系统的主要优化、保障机制。其他让程序猿们在建设过程中不断扩展。
一站式、多租户、云… 平台思维告诉我们,要做大、就要进行“赋能”。把多租户的管理和运营考虑进去。让租户能够定制化、自运营。
结合多租户的特性,考虑领域模型的运营优化体系,数据补充等。
考虑依赖的外部服务,做好技术选型,为程序猿扫雷。

提出技术目标,激发程序猿在系统建设的过程中,反哺架构。




写在最后

生活不止眼前的苟且 还有诗和远方的田野


我们每天都做着重复劳动的工作,在成长的路上感到孤独、迷茫、空虚寂寞冷;每天也从网上学习高精尖科技,看各路大神BB,却越发感受到自己成长的压力;


眼到、手到、心到,如何让我们在看似平凡的岗位中做出不平凡?如何让我们快速度过感性认知阶段,让知识成为自己的,并进入理论指导实践的阶段?


EDUCATION,是苏格拉底发明出来的,是三个词根的拼写,前面那个“E”是向外的意思,“DUCE”是引导,“TION”是名词,引导出来。所谓的教育,就是把一个人的内心,真正引导出来,帮助成长成自己的样子。

李克强总理最近提到: 分享经济是拉动增长的新路子。—— 李克强

我也套用句式:分享是拉动成长的新路子 -半兽人药剂师

温故而知新、可以为师也,定期对自己所做工作进行总结、分享、交流,能够让我们逐步从“术”的层面进入“道”的层面,这也是一种改善自身能力的行为模式;正所谓“吾尝日三省呼己,知其然更知其所以然”。


                                                        中生代技术群微信公众号

                                                da9312524921e637b684eed7bf3249db58f7badc
目录
相关文章
|
6月前
|
Linux 调度
单片机面向对象思维的架构:时间轮片法
单片机面向对象思维的架构:时间轮片法
82 0
|
3月前
|
设计模式 算法 PHP
深入理解PHP中的数组操作探索编程之美:从代码到架构的思维转变
【8月更文挑战第24天】在PHP编程中,数组是基础且强大的数据结构。本文将通过浅显易懂的方式,介绍如何在PHP中高效地操作数组,包括创建、遍历、排序和过滤等常见任务。无论你是初学者还是有经验的开发者,这篇文章都会带给你新的启示。 【8月更文挑战第24天】在编程的世界中,代码不仅仅是冰冷的字符排列,它承载着思想、解决问题的智慧和创新的灵魂。本文将通过个人的技术感悟,带领读者从编写单一功能的代码片段出发,逐步深入到整个软件架构的设计哲学,探索如何将代码块转化为高效、可维护和可扩展的系统。我们将一起见证,当代码与架构思维相结合时,如何引发技术实践的革命性飞跃。
|
6月前
|
设计模式 供应链 安全
如何在短频快的节奏中做好技术?业务开发必会的架构思维
本文提供一种业务架构设计模式:从业务&技术两个角度提炼出一个基础思维框架,供业务线开发同学参考。
如何在短频快的节奏中做好技术?业务开发必会的架构思维
|
6月前
|
项目管理 微服务
拥抱不确定性:技术实践中的敏捷思维构建高效微服务架构:后端开发的新趋势
【5月更文挑战第29天】 在快速变化的技术世界中,不确定性已成为常态。本文探讨了如何在技术实践中运用敏捷思维来应对不确定性,提出了一套实用的策略和心态调整方法。通过案例分析,展示了在项目开发、系统设计以及团队协作中如何有效地应用敏捷原则,以适应需求变动、技术演进和市场波动。文章强调了持续学习、灵活适应和以人为本的管理对于维持技术实践敏捷性的重要性,旨在为技术人员提供一种面对不断变化环境的心智工具箱。
|
6月前
|
存储 Java 编译器
用王者荣耀告诉你,什么叫类与对象,思维图+核心+架构让你一步到位
用王者荣耀告诉你,什么叫类与对象,思维图+核心+架构让你一步到位
|
架构师 数据可视化 测试技术
架构设计方法论和思维
架构设计方法论和思维
|
架构师 算法
架构师培养计划-无限思维——变量
架构师培养计划-无限思维——变量
68 0
|
设计模式 运维 架构师
一站到底!阿里新产架构进阶宝典限时开源,架构不止于思维
关于程序员如何成长这个问题在网上一直备受争论,可能有些人都会觉得Java程序员未来的路线无非就是︰一直往上爬,爬不动了就洗手不干了。目前的状态就是在公司不停地复制粘贴,再复制再粘贴的过程,基本上没机会去设计整个(部分)系统,也不会去设计数据库,要么就是系统就百八十人在用,也不考虑性能,代码堆完就OK了。每天的工作一样,基本上都在混日子,想跳槽跳出去工资也涨不了多少,年纪轻轻地就处于养老状态了。
|
前端开发 架构师
前端学习笔记202304学习笔记第八天-架构师的思维设计需求1
前端学习笔记202304学习笔记第八天-架构师的思维设计需求1
53 0
|
前端开发 架构师
前端学习笔记202304学习笔记第八天-架构师的思维设计需求1
前端学习笔记202304学习笔记第八天-架构师的思维设计需求1
53 0