您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
以架构的思维看世界
 
作者:灿岩 来源:csdn 发布于:2017-5-22
   次浏览      
 

为什么要聊聊架构?

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

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

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

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

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

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

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

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

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

小而美的问题驱动

无论是域架构、业务架构、系统技术架构,很大程度上都是问题驱动式的,通过问题直接找准解法,在很多人看来,这已经是最后一步了。为对应的问题找出解法,这难道不就是解决方案吗?剩下的就只要找一些码农来写代码就行了啊,还有什么要做的?

然而,结合前面所述的中台建设、产品化等要求,万里长征只开始了第一步。

下面我们从一个看似简单的问题域开始,以通用架构思维,搭建解决方案:

识别一句话中的错别字

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

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

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

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

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

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

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

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

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

服务渠道、能力输出

下面继续思考文章开头提到的,怎么“赋能”,这是一个很实际的问题,也是产品化比较重要的一步。这里我们要整体性的考虑很多东西,后端世界的各种分布式、高并发、高可用等各种点子喷薄而出,各种名词、砖头都想要往架构图上去堆了。作为各位的梦想导师,此时需要提醒大家的是,越是到这种感觉“呼之欲出”的时候,越需要谋而后动,国足都能做到90分钟而不射,我们也要克制所谓的“条件反射式画图”的冲动。

在考虑赋能的时候,我们通常反问自己三个问题:

提供什么样的服务方式?

如何解决服务性能问题?

为哪些人提供服务?

在服务方式这里,这里也有模式可循,稍微套一下,看能否套上:

统一实时服务

分布式实时服务

嵌入式组件化

T+1服务

调式服务

于是我们的架构再次长出一块儿服务渠道层:

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

针对统一服务和分布式服务的特性,系统架构统一考虑搞一层缓存来做数据处理,减少对数据库的压力:

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

管理、运维与多租户赋能

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

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

然后,我们就要站在租户角度去思考,如何完成所谓的“一站式管理”、“一站式运营”了。

站到这个层面,我们顺理成章的又要考虑几个问题了:

如何让租户方便的“入驻”?

系统如何管理各租户的模型?

租户如何管理他的团队?

租户如何管理功能?

租户如何运营功能?

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

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

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

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

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

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

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

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

外部依赖与系统边界

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

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

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

设定技术目标

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

在大图的建设上,在通过颜色区分已建能力和待建能力,就让架构师也具备了一些大PM的职责。而在这张大图上,架构师也还兼顾着一些远期规划的角色:

这个盘子有多大?能发展几年?

领域深度够深吗?具备核心能力吗?

这个方向能指导我们团队扩大到什么规模?

这种建设能力可以冲出公司,走向世界吗?

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

找一种思维方式看世界

所以,我其实也是标题党。

进来的架构师,或者立志走在架构师路上的同学可能看完后会这样问:

这个和我们平时看的技术架构、业务架构都不一样啊

你是不是把业务架构和技术架构搞混到一起了啊,noob

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

架构存在的作用,在这里也不进行定义和描述,因为一样会有同学来和我争论定义的准确性。

那么本文其实想表达一种思维方式,当你面对问题难以下手时候,不妨尝试这套武功秘籍,换个角度看世界。

总结

从一个小而核心的问题开始,找出解决方案,作为核心能力输出。

思考支撑这种核心能力输出的领域模型。通过领域深度不断的扩展系统可承载的业务边界(再次强调,这点很重要)。并扩展能够输出的核心能力。

以产品化的视角,考虑扩展服务的方式、渠道,让系统更灵活,能够适应更多的用户。

考虑服务性能、体验,设计好本系统的主要优化、保障机制。其他让程序猿们在建设过程中不断扩展。

一站式、多租户、云… 平台思维告诉我们,要做大、就要进行“赋能”。把多租户的管理和运营考虑进去。让租户能够定制化、自运营。

结合多租户的特性,考虑领域模型的运营优化体系,数据补充等。

考虑依赖的外部服务,做好技术选型,为程序猿扫雷。

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

下面就是那些长得很像的架构图,也能够让你来搭建传说中的“左中右结构”、“事前事中事后”结构,看待事情的角度不同,但呈现方式和思维模式很类似。

   
次浏览       
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践