| 为什么要聊聊架构？
又到一年财年底，又到了各架构师们交配、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，并以此为荣。
架构存在的作用，在这里也不进行定义和描述，因为一样会有同学来和我争论定义的准确性。
那么本文其实想表达一种思维方式，当你面对问题难以下手时候，不妨尝试这套武功秘籍，换个角度看世界。
总结
从一个小而核心的问题开始，找出解决方案，作为核心能力输出。
思考支撑这种核心能力输出的领域模型。通过领域深度不断的扩展系统可承载的业务边界（再次强调，这点很重要）。并扩展能够输出的核心能力。
以产品化的视角，考虑扩展服务的方式、渠道，让系统更灵活，能够适应更多的用户。
考虑服务性能、体验，设计好本系统的主要优化、保障机制。其他让程序猿们在建设过程中不断扩展。
一站式、多租户、云… 平台思维告诉我们，要做大、就要进行“赋能”。把多租户的管理和运营考虑进去。让租户能够定制化、自运营。
结合多租户的特性，考虑领域模型的运营优化体系，数据补充等。
考虑依赖的外部服务，做好技术选型，为程序猿扫雷。
提出技术目标，激发程序猿在系统建设的过程中，反哺架构。
下面就是那些长得很像的架构图，也能够让你来搭建传说中的“左中右结构”、“事前事中事后”结构，看待事情的角度不同，但呈现方式和思维模式很类似。
|
