对"架构"的解析
前言
平常在工作中，经常能听到产品架构、功能架构、系统架构、技术架构等各种关于架构的名词，这就引申出了几个问题，到底是什么架构，架构有什么用，架构都有哪些，我们该如何设计架构等等。本篇文章是从以下三个方面来对架构进行阐述的：
- 架构的定义
- 架构设计的关键要素
- 如何做架构
架构的定义
定义
在去讨论架构的时候，首先了解下它的定义。
架构： 是人们对一个结构内的元素及元素间关系的一种主观映射的产物。也可指构筑，建造。引用自百度百科
软件架构： 为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。引用自百度百科
从这两个词的解释中都可以看出，做架构设计其实就是找到架构内都有哪些元素，并且建立元素之间关系的一个过程，而架构是这个过程的产物。根据面对的事情，会在架构前面加上不同的修饰词来描述其要解决的具体问题，例如产品架构、功能架构、技术架构等。
作用
相对具体的编码来说，架构设计是偏向于宏观层面的，它是从顶向下解决问题的。这个过程其实就是将一个问题从大到小的进行拆解，最终会有很多个子问题，并且这些子问题是以某种关系关联起来的。类似“分治法”：
把一个复杂的问题分成两个或更多的相同或相似的子问题，直到最后子问题可以简单的直接求解，原问题的解即子问题解的合并。引用自维基百科
以特征平台的升级过程为例，特征平台在当时面临两个核心问题：
- 效率问题 它提供的功能已经跟不上业务的发展，做为工具，使用它的效率其实是很低的。
- 定位问题 在之前特征平台仅仅定位为工具，没有对内容作出管控，也没有主动产出对用户有用的内容，在这种情况下平台的价值增长空间是非常有限的。
抓住核心问题依赖我们看待事物的方式
通过分析，将解决这两个问题分解为三个子问题：
- 对数据进行治理 引入基础数仓团队，保证数据能够持续产出，并且共同解决数据质量问题和使用数据效率问题。
- 调整产品架构 清晰规划每个系统的功能边界和它们之间的依赖关系，减少重复开发，提高团队开发效率。
- 优化技术架构 根据产品的规划，重新划分系统功能模块以支撑产品的功能。
子问题1、2解决核心问题效率问题，平台定位问题, 而子问题3去形成一个实际的系统来支撑子问题1, 2并且解决效率问题。
再往下拆解就是把以上问题拆解为更小的子问题，以下仅列举部分子问题：
- 制定每个功能模块可实施的产品和技术方案：
- 系统整体的PRD，能让所有开发人员和产品人员对最终的产品有个直观概念。
- 系统与外部交互的具体流程，例如特征平台如何支撑用户画像系统，算法人员如何在特征平台上获取他们想要的数据。底层的技术架构会决定上层用户如何使用系统，上层用户的使用方式也会影响底层的技术架构。因此一定要结合两个方面制定最合理的技术方案。
- 系统内模块间的交互流程图。
- 元数据的ER图。
- 计算引擎的模块的系统架构，可实现流程。
- 监控模块的系统架构，可实现流程。
- 产品要制定有效的数据运营策略：
- 细化每个系统子模块的产品细节。
- 制定数据的规范体系，并能持续迭代以跟上业务的发展，例如业务板块、业务域的定义是会变化的。
- 收集并分析用户的需求给所有特征建立分类体系，提高用户查找效率与体验。
- 分析监控平台提供的质量数据，下线质量不好的特征，推荐质量好的特征，跟踪并解决数据提供方的质量问题。
- 根据质量监控、特征使用情况，制定特征排序推荐策略。
- 收集每个特征的优秀案例，集成到平台上，以提供给数据消费方参考。
- 收集特征收益，反馈给数据提供方以提高其积极性。
最后就是落实到具体的人来去执行。
这个例子展示了将一个大问题逐层拆解成子问题的过程，每一层都有产出对应的视图（架构图），用于规划下一层都有哪些元素，要做什么。对最后的子问题求解就非常简单了。这中间涉及到的三个关键要素：事、人、物。
三个关键要素
是否能将大问题拆解成小问题考察的是架构设计能力，这个能力是与架构设计过程中的三个关键要素事、人、物息息相关的。
事情
指要做的事情，这个事情并没有固定的范畴，既可以是要解决的问题，要优化的某项性能指标，也可以是要提升的某项业务指标，等等。真正做事之前有两步：
1. 该怎么找事情
- 上级分配
- 从现状中总结，例如本次特征平台的问题就是从现状中进行总结分析得出来的
- 创新，经过对所负责业务、外部相关信息的整合分析得出可以扩展业务边界的事情
2. 该如何分析事情
这个可以用 看待事物的方式 方式来拆解，它的目的在于抓住核心问题，或者将要解决的问题扩大化产生更大的收益。两个关键点:
- 抬高视角看事情，收集更多的信息。视角越高对问题的判断就越精准，也越能看清事情的走向，但这个其实也是最难的，也是我们需要持续提高的。
- 如何提高视野。
- 如何收集信息。
- 判断这件事情真正的核心问题，考察的是看问题的角度和对问题的认知能力。
- 如何处理收集到的信息，建模分析。
- 如何验证分析结果。
- 根据现有信息多向前推断几步，即把握事情的发展方向。
对事情分析之后也可能会产生新的事情，那么就需要：
- 循环步骤2，直到没有新的事情为止。
- 分析结束后，这个时候会产生一个事情列表。
- 每件事情即可以是孤立的，例如将一个描述模糊的事情转化为具体的事情，那么只需要关注具体的事情即可。
- 也可以是一个递进关系，例如事情B是事情A的进化方向，做完事情A才能做事情B。
- 统计每件事情的收益、可行性，评审然后拍板。
特征平台的重构分为三个阶段，站在不同的视角去看问题就形成了同一件事情的不同理解：
第一个阶段
考虑实时特征项目相关的问题，暂时没有考虑其它问题。
第二个阶段
从更大的视野看前一个问题，这个时候考虑的是整个团队和用户当前的痛点。从实时特征项目面对的问题切入，扩大到离线特征的处理，再扩大到整个团队与特征相关的项目。
第三个阶段
同样的信息，从另外一个角度看问题，主要是技术之外的思考，如何使产品跟上业务的发展，最终引入数据团队。前两个阶段主要考虑的是技术方面的问题，这个阶段考虑的是产品价值和团队之外的事情。
这三个阶段其实也是一个递进的关系，从小问题出发到扩展到一个与整个团队相关大问题，直到形成前面提到的两个核心问题。解决最终两个问题的收益是更大的。
人员
指与这个事情相关的人或者组织，事情一般是由人产生的，而事情最后是需要人来落实执行下去的。那么这个过程中涉及到两个问题：
- 如何确定真正的需求方，并能找到他们的核心需求
- 如何保证执行方能准确无误落实具体的事情
那么就需要我们具备以下能力：
- 良好的沟通能力
- 分析各方核心诉求与要做事情关系的能力，这个能力的本质是将自己的诉求与大家的诉求关联起来，与每个人产生关系之后事情就能更好的推动下去。
还需要思考一个身份的问题，这也会决定我们做事的方法和考虑事情的角度。可以将与自身相关的人员按部门内外、身份两个维度来划分，部门内有上级、平级、下级，一般来说可以将其它单个部门看做一个整体。部门内需要考虑的是资源分配、同事间的协作，分析每个人的优缺点、培养下属，增强团队凝聚力等。
特征平台重构过程的每个阶段关联的人员：
- 项目已有人员，做事的动力源于看到重构项目的收益
- 涉及到整个团队的工作，从现状分析、初始方案、收益三个方向让领导认可这个方案，图文并茂的详细方案让同事理解这个方案的目的，对他们个人的收益，从而保证事情能顺利执行下去
- 与基础数仓团队跨部门合作，在于找到团队之间的互补点，达到合作共赢
物件
工具是事情最后的载体，在软件行业来说，它形成的产物一般是某个平台、某个系统、或者某个服务。 工具既可以是具体的东西，例如Flink、开发框架、开发平台，也可以是沉淀下来的方法、经验。工具的集合相当于工具箱，也就是个人的知识面，在工作的过程中，是需要不断的向这个工具箱中添加新的工具，为了更好的完成目标也需要加深对每件工具的理解。为了提高这方面的能力引申出两个问题：
- 扩宽知识面
- 往哪个方向扩宽
- 如何扩宽
- 如何理解某件工具
- 原理分析
- 实践
这个过程可以参考 构建个人知识体系
特征平台的相关技术用到的相关工具：
- 软件 Flink，Spark，MapReduce, Redis, Elastcisearch, Hive，Presto, Mysql，Java，网络知识，操作系统
- 方法 建模语言，数据治理沉淀下来的方法论，微服务
总结
最后总结下如何利用这三个要素产出具体的架构方案。
结合对事与人的思考，形成了产品架构，功能架构，根据对工具的掌握最后再形成技术架构。
产品架构 确定了每个产品的定位、功能边界、面向用户，和每个产品之间的关系、层次。
功能架构 根据产品架构，将一个产品划分成具体的功能模块。
技术架构 将相关的工具组织起来完成最后的执行，主要是用来描述各个模块之间如何对接。
将模块拆解成具体的可实施方案，例如er图、程序的流程图等
在形成最终的方案之后，还需要再向用户确认是否能够满足他们的需求，而且如果可能的话，还应该多考虑一步，思考业务的发展方向，在将来业务方需求变化的时候，以很小的成本就可以满足他们的需求。从技术上，还可以从稳定性、易用性、可扩展性、性能等方向考察架构。
在做每件事情的时候，尽量多往前思考几步，并且尽量提升视野的高度。