关于技术方案与架构宣讲的思考

关于技术方案评审和架构演进宣讲的时候，我有的时候其实是比较难区分哪些时候适合使用架构图，哪些时候适合使用流程图。

当然技术评审和架构宣讲本身的目的也是不同的，比如：技术评审可能更是靠近问题本身，我们针对现有系统存在的一些问题去解决，并输出方案；或是我们系统对于未来想要支撑的业务能力上目前存在还存在哪些不足和缺失，那我们需要补齐和完善，我们输出一个面向未来理想态的一个方案。因为新方案我们更关注于风险可控与可落地性，所以可能更要求流程图多一些，这样可以知道我们的影响链路，上下游配合，流程衔接，边界分工等情况，更具体也更可控。

而架构宣讲的目的可能又是不同，比如介绍我们的产品或者系统，可以有架构图，是为了展示我们系统的能力蓝图，以及业务支撑，架构图更多的是展示一种“现状”说明我们的能力，但是架构图所表现的东西可能更宽泛一些，所以可能不适合去做方案评审和落地指导，因为他可能缺少细节或是边界与联通。

当然和屁股也有关系，就是如果你是个高p，负责的盘子够大，通过架构宣讲和架构图的方式规划整个业务架构就无可厚非了。

架构宣讲中的技术架构应该是具备系统架构的普遍特征。

首先说下系统架构的概念。

“系统架构”可以拆分成两部分，即“系统”和“架构”。

百科中给“系统”的定义是“若干相互联系、相互作用、相互依赖的要素结合而成的，具有一定结构和功能，并处在一定环境下的有机整体”，从这句话可以提炼出两点内容：

一是整体与部分 (由要素结合而成的)；

二是结构性 (具有一定的结构和功能)。

所以谈系统一定具有多个组成部分，并且这些部分是相互作用的。

再看架构在百科中的定义是：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

其中一个重要的词汇是“抽象描述”，换言之，架构是把系统中的整体结构和组件之间的关系体现出来。

至此，总结出第一个结论：系统架构是描述系统要素之间的关系。所以他更适合一种偏“事后”或“最终态”的宣讲。

接着再深入分析什么是系统架构，架构又拆分成两个字“架”和“构”，“架”就是“加”和“木”，它源于建筑领域，把木头连接起来就是架，“构”就是结构的意思。

所以，“架构”就是把“木”按照一定的结构连接起来。“木”就是系统中的要素，技术架构一定是解决目前业务上的问题，一般而言，技术架构要解决的问题有：高并发、高可用、高性能、高扩展等。

再来看“技术方案”。

在设计方案时，要找到问题的本质，拿高并发来讲，它是有限的资源应对大量的请求，矛盾很明显。如何去解决这个问题呢？

从矛盾出发，分别在资源和请求处理上做文章，这样从前端、网络、后端可以设计出一套系统化的方案出来。

当然这个是个偏技术的例子，从业务切入也可以梳理相关问题，比如业务越来越多，定制化开发成本高，是否具备一种配置化能力去做这件事情，比如能力过于分散，协调成本高，沟通不闭环，是否可以做系统能力收敛与融合，形成一个特定业务的解决方案平台，解决聚类问题。

最后，如何理解技术架构公式中的“技术组件”呢？

技术方案中会涉及到使用哪些技术组件，如分布式缓存、消息队列、分布式定时任务、网络通信等，技术方案会根据需要选择一个或多个技术组件来完成目标。

单纯的技术组件本身是没有技术价值的，它应该是放在相应的业务场景下才会体现出价值来的。

技术问题的作用是确定问题、支撑业务；

技术方案的作用是解决之道、中心灵魂；

技术组件的作用是基础能力、物理支撑。

所以技术方案才是灵魂，技术组件是基础能力，中间件是基础能力，但它并不是技术架构的全部，技术架构的灵魂是技术方案。