架构学习(转)

架构设计不是架构师的专属工作，对非技术人员甚至是开发人员来说，从实实在在的需求到高神莫测的架构设计仿佛是一个神秘的过程，只有具有架构师头衔的人才能掌握各中玄妙，这篇文章就是从最基本的事物关系来回答如何根据需求进行架构设计的问题。

根据我前面的文章，架构的本质是事物与事物之间恰当的关系，不同领域的架构，其事物的指代不同，比如对于组织架构而言，事物指的是人与机构；建筑架构，事物指的是钢筋混凝土与空间。那在软件领域，事物指的是什么呢？我们知道，软件系统的本质是人类将自身无法处理的大量业务相关的数据进行筛选分类，并转换成计算机可以识别的格式，借助其强大计算能力来辅助处理。因此在软件领域，架构中的事物指的是业务数据与基于运算能力的业务逻辑，说的再宽泛一点就是数据与处理数据的计算能力。那么，架构设计其本质就是寻找数据、计算以及它们之间的平衡关系，这里面包括三个方面的要素，即数据、计算、以及平衡关系，其中数据和计算是架构设计的基础，根据实际业务需求一般不难找出，而平衡关系是综合考虑多方面得到的一种状态，也是衡量一个架构设计优劣的核心要素。
　　（一）数据

　　在对一个系统进行架构设计时，首先我们需要做的就是依据本系统所承载的业务需求，找出需要处理的最重要或最核心的数据，这些数据一般隐藏在线下的纸质材料里，或者记录在日常办公的笔记里，或是约定俗成的共同认识，只要从实际业务出发，找这些数据并不难。如果你无从下手，这里有个小窍门可以利用，找一个出现率很高的业务，在该业务处理前尽可能多的记录一些可能与该业务相关的数据状态，待业务处理完成后，再次记录，并与之前的数据进行比较，那些发生了变化的往往就是我们需要重点关注的重要数据。举例来说，如果这是一个政府行政办公的系统，那么办公流转过程就是数据，每个环节办理状态就是数据；如果这是银行信用卡管理系统，那么用户信用卡可用金额、账单、有效期等状态信息就是数据，每笔刷卡流水就是数据；如果这是电子商务系统，那么商品信息、用户订单、购物车信息就是数据。。。等等，所有那些在实际业务过程中会变化的，并且是与该业务紧密相关的数据，都是我们需要找到的数据，在所有已经找到的数据中，再依据实际业务的重要程度，找出最重要最核心的数据，作为在架构设计中我们需要重点处理的对象，其他次重要的数据在核心数据充分处理的前提下作为平衡关系的备用因素。
　　（二）计算　　

　　重要数据找到后我们还需要确定如何处理这些数据，即计算，说的明白一点就是计算逻辑是什么，计算逻辑类似但并不完全等同于业务逻辑，它是业务逻辑在计算机世界里的一种体现，业务逻辑在真实世界里需要考虑人、时间、空间的因素，而计算逻辑在计算机的世界里，是二进制码、CPU、内存、存储、网络等因素，还是以上面的例子来说，政府行政办公系统需要将线下的纸质签字盖章从发起请求到办结的全过程搬移到线上由系统处理，那就需要转化成线上的在线申请、办理、流转、通知、办结、存档等过程，这些过程在线下可能有不同的部门来负责，但是线上将由我们设计的系统完全支撑；对于银行信用卡管理系统，需要将银行对信用卡的管理业务转化成具体的设置或查询可用金额、账单、有效期等信息的功能，还有记录和统计用户消费流水等，如果业务有需求，甚至需要根据用户的消费流水对用户画像，以便进行精准营销等所谓的大数据分析模块；电子商务系统也是一样，需要系统提供向用户展示商品信息，记录用户点击购买后的购物车信息，创建或更新用户的订单信息，以及跟踪订单从仓库打包到送达的物流信息。。。等等，这些都是我们对数据进行的动作，而动作不是我们凭空想象出来的，是从实际的业务处理转化到计算机领域而来的，在转化的过程中我们需要时刻对应现实中的处理动作如何转换成计算机世界里的处理数据的能力。由于寻找计算是一种业务动作的转化，在转化时我们可以多问自己期望系统应该如何帮我更好的处理数据，那些利用机器能很好的完成而人工较难做到的但又是经常需要做的且与业务相关的动作一般都是我们需要找的，常见的动作有数据跟踪记录、查询统计、修改更新、导出展现、汇总分析等。当然有一点需要注意，我们在寻找计算因素的时候一定要基于计算机世界的客观现实，毕竟计算机不是万能的。

　　（三）关系
　　明确了数据及如何处理数据，架构设计接下来要做的就是如何平衡好各种相互影响的关系，这些关系是所有我们能想到的会影响到系统的矛盾体，如数据处理效率与处理能力的关系、数据体量与存储能力的关系、数据展现与用户要求的关系、系统部署与网络环境的关系、系统建设与建设成本的关系、系统易用性与客户要求的关系等等，在做架构设计的时候要尽可能多的考虑到这些关系，并根据实际情况划分关系的重要程度，重点保障那些重要性高的关系，毕竟再完美的架构设计也无法平衡好所有的关系，从这个角度来说，架构设计是一种平衡的艺术。当然，要准确找出这些关系，并对它们划分重要性等级，还需要做到按等级进行平衡是需要经验积累的，非一朝一夕之功，这也是人人都能做架构设计，但不是人人都能做好架构设计的原因。好在这一步并不是完全无规律可循的，首先我们讲如何找出这些关系，虽然涉及影响一个系统的矛盾体很多，但是大致上我们可以从以下3个方向来挖掘出这些关系：

1. 第一个方向是与人相关的，这里的人包括筹建系统的甲方、建设系统的乙方、以及使用系统的用户，对于筹建系统的甲方来说，他一般关注系统的建设进度、成本、质量等，对于建设系统的乙方来说，重点会关注建设范围、风险、开发工具、实施环境等，而对于用户来说，更关系系统易用性、界面友好，操作舒畅、能帮其解决实际问题等。涉及到与人相关的关系，除了从经验中获取，更重要的是需要在前期系统设计的过程中通过调研的方式，多与相关的干系人沟通，从他们那里获取，这也是为什么系统建设一般都是有需求调研过程的原因。针对与人相关的关系这部分设计内容一般体现在架构设计说明书中的概述里，包括项目目标、项目背景及其他说明等，当然与用户相关的一般也会在非功能性上有所体现，如易用性、可用性、安全等；
2. 第二个方向是与外部系统相关的，主要指其运行所在的操作系统及服务器，以及与之交互的外部系统，系统需要运行在服务器特定的操作系统上，受服务器操作系统计算存储网络等因素影响，需要考虑服务器计算能力是否能处理数据、存储能力是否足够、网络是否稳定、如果服务器计算存储网络能力不够如何扩展等；与外部系统的交互方面，本系统需要从外部系统获取哪些数据与能力、需要为外部系统提供哪些数据与能力、交互方式是什么、交互协议如何等。一般来说，服务器的能力总是会有不够的，尤其是设计大数据量处理，大量用户同时访问的系统时，这就需要我们根据系统的特点提前做好扩展的设计，高并发处理、分布式理论、多机房部署等这些技术概念可以给我们很好的指引，这也是为什么架构师一定要眼界开阔的原因。这部分的设计内容一般体现在架构设计说明书中的逻辑架构、技术架构、接口设计、部署架构、以及相关性能、可维护、可扩展等非功能性设计上；
3. 第三个方向是数据相关的，数据是系统处理的主体，需要划分本系统所处理的数据与外部数据的边界，明确与外部数据的流向关系，还需要根据实际业务来区分数据内部之间的关系，数据如何划分、各部分数据的边界在哪、与整体数据的关系如何等等。在划分与外部数据的边界时要基于本系统所承载的实际业务内容，从业务出发，那些只受本业务影响的数据肯定在边界内，而本业务与其他业务共同影响的还需要进一步分析哪方是影响主体，如果本业务是影响主体，那么在边界内，但是需要考虑提供给外部系统的交互接口，如果本业务非影响主体，那么再看是否有间接影响或关联影响，一般来说这部分数据都要考虑与外部系统的交互关系。对于边界内的数据关系也是如此，可以根据业务特点划分一些区块，每个区块内又是一个相对独立的单元，与相关的其他区块单元存在哪些数据上的直接或间接影响，他们之间如何交互等。所有这些关系都是我们需要发现并在架构设计时考虑的。针对这部分的设计内容一般体现在架构设计说明书中的数据架构、整体架构里。

　　人、外部系统、数据是我们在发掘关系时可以参考的方向，根据系统各自的特点，在架构设计过程中还会有一些需要实际去考虑的关系，这些关系一般都是所谓的系统最大的特点或特殊情况，常见于重大需求，特色需求，亮点需求等形式，一般也不难找出。待把所有这些关系找出后，可以先做一个粗略的重要性分级，分级的依据是关系的相关性，一般是重要需求相关>特色亮点需求>甲方相关>用户相关>乙方相关>外部系统相关>外部数据相关>内部数据相关>其他次重要的数据，在进行架构设计时优先满足重要性高的关系，得出一个基本的架构雏形，再根据弱一级的关系不断地优化完善架构模型，待大部分关系都可以满足后，架构设计也就出来了。当然，很多关系之间都是矛盾的，比如筹建系统的甲方要求的低成本与高质量、系统间数据交互与操作舒畅等，需要我们在做架构设计时不断权衡，尽可能的兼顾,对于实在无法兼顾的，需要进行权衡取舍。
　　综上来说，架构设计就是一个找准数据主体、明确处理逻辑、平衡矛盾关系的过程，需要根据实际业务进行适当的抽象，使之适合体现在计算机的世界，每一步都需要我们明确主体，分清主次，并尽可能的平衡更多的关系，这需要不断的积累经验，也靠一点悟性，有时候也需要一些灵感。无论如何，架构设计都不只是架构师的工作，而是任何人都可以做的一项有趣的工作，愿你开完此篇文章后对架构设计不再迷茫，逐步成为一个优秀的架构师。