架构设计三部曲（转载）

Posted 2021-04-10 编程阁楼

1. 如何做架构设计

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

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

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

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

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

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

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

2.如何写架构设计说明书

架构设计是需求分析到软件实现的桥梁，也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。在架构师整个的成长过程中，必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。

那么到底如何编写架构设计说明书？该说明书应该包括哪些方面的内容呢？我们知道，架构设计说明书是阐述系统架构具体内容的，架构的本质是呈现三大能力：即系统如何面向最终用户提供支撑能力、如何面向外部系统提供交互能力、如何面向企业数据提供处理能力。因此从这个角度看，对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能力的，让我们逐个分析：

1. 系统如何面向最终用户提供支撑能力：这一点是要从系统自身的能力来看，即本系统到底应该具备哪些功能，各功能间如何协作以满足支撑最终用户的使用，其实就是要讲 系统的功能架构或逻辑架构 ，回答系统从功能粒度上划分了几个功能模块或子系统，各模块或子系统之间的 内部接口关 系如何等问题。当然还有一个需要考虑的问题，在纵向维度上，随着架构设计理念的不断发展， 逻辑架构模型从最初的展示-数据两层模型，到展示-逻辑-数据（所谓的MVC）三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型，不同层次表明系统内部设计的精细程度，因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。尤其是对于Browser/Server架构模式的MIS类系统，这种层次更为常见。另外，用户相对于机器来说对系统提供的能力是有个人喜好要求的，不仅要求系统能提供支撑，而且还要更加稳定的、更方便的、灵活的、快速的等提供，这就需要在架构设计说明书中增加所谓 非功能性的设计 ，即需要描述系统的性能、高可用、可扩展性、可维护、安全性、可移植性等。
   
2. 系统如何面向外部系统提供交互能力：这一点是要把系统当成一个完整的整体，阐述它如何与外部的系统发生调用关系，外部系统为它提供了哪些开放接口，它又为外部系统提供了哪些 外部接口 和能力，同时，在这种相互的调用关系中它处于整个IT架构的何种位置，这其实就是在说系统的 整体架构。 另外，如果我们把操作系统和硬件服务器也当成一类特殊的外部系统的话，就需要说明系统如何基于操作系统利用硬件服务器来提供计算、存储、网络等能力，系统如何把自己拆分成不同的部分以便部署在服务器上，这其实说的是 部署架构 。
3. 如何面向企业数据提供处理能力：信息系统的原始驱动力就是人们需要借助计算机的强大计算能力来辅助处理大量数据，从而形成可理解的信息，并最终形成可掌握的知识。因此数据处理是系统的根本目的，至关重要，在架构设计说明书中需要单独描述系统对数据的处理能力，即我们所谓的系统 数据架构 。这还是可以从对外和对内两个角度来看，对外即需要说明本系统处理的数据在整个企业数据流中所处的位置，与相关的上下游数据之间的关系，本系统需要从数据上游的外部系统获取哪些数据？又需要为数据下游的系统提供哪些数据；对内需要说明本系统根据业务需求设计了哪些关键数据表，它们之间是何种主外键关系，是否需要从外部导入数据为系统做数据初始化等。当然还有对数据管理的描述，包括如何做数据冗余设计，备份机制，数据安全管理机制等。

        好了，分析完这三种能力，我们几乎就找出了架构设计说明书中应该包括的内容，包括整体架构、逻辑架构、数据架构、部署架构、内外部接口、非功能性设计等，如果纯把架构设计作为理论研究，有这些也就够了。但是现实中我们编制架构设计说明书毕竟是用来指导我们后续系统开发的，是需要真正落地实施的，因此就会涉及使用何种技术实现？有哪些关键技术？用到了何种成熟或开源技术组件？复用了哪些之前的技术成果？等等，同时也包括对技术风险的考虑与预防措施。所有这些就是 技术架构 的内容。
    综上，我们就可以得到一份完整的架构设计说明书的结构及应该包含的内容，其大致章节应该是这样的：

1. 文档概述：包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节；
2. 整体架构：主要从整个IT层描述系统所处的位置，与周边关联系统之间的调用关系；
3. 逻辑架构：系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述；
4. 接口设计：包括系统间的接口设计以及内部功能模块之间的接口设计；
5. 数据架构：本系统与上下游系统间的数据流关系，以及本系统关键数据表设计、数据管理策略等；
6. 技术架构：实施此架构需要用到哪些技术能力，有哪些复用能力及风险；
7. 部署架构：系统如何部署，网络拓扑上有何要求，对硬件服务器有何要求，需要几台，是否需要优化服务器参数；
8. 非功能性设计：性能、高可用、可扩展性、可维护、安全性、可移植性等。
9. 其他说明：如特别约束条件、风险考虑、进度要求、政策限制、环境影响等；

以上，便是我认为一份较为完整的架构设计说明书应该包括的内容了。

3.如何评审架构设计说明书

其实从编制架构设计说明书的角度来看，也可以阐述具体如何编写架构设计说明书，就像高考作文一样，评审总是有些采分点的嘛，那么对于编制架构设计说明书来说，哪些是我们应该准备的采分点呢？我们在编制的过程中需要重点注意哪些章节的哪些内容呢？这就是我接下来想和大家分享的。
    根据第一部文章我们知道一篇架构设计说明书大致章节应该是这样的：

1. 文档概述：包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节；
2. 整体架构：主要从整个IT层描述系统所处的位置，与周边关联系统之间的调用关系；
3. 逻辑架构：系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述；
4. 接口设计：包括系统间的接口设计以及内部功能模块之间的接口设计；
5. 数据架构：本系统与上下游系统间的数据流关系，以及本系统关键数据表设计、数据管理策略等；
6. 技术架构：实施此架构需要用到哪些技术能力，有哪些复用能力及风险；
7. 部署架构：系统如何部署，网络拓扑上有何要求，对硬件服务器有何要求，需要几台，是否需要优化服务器参数；
8. 非功能性设计：性能、高可用、可扩展性、可维护、安全性、可移植性等。
9. 其他说明：如特别约束条件、风险考虑、进度要求、政策限制、环境影响等；

那么我们依次来看，每个章节在评审过程中需要关注哪些问题，编写架构设计说明书的人员有针对性的需要提供哪些内容：

（一）文档概述
      对本架构设计说明书本身进行解释，需要说明清楚本文档背景，即为什么有这个文档，文档的内容范围，预期的读者，包括了哪些需要同步参考的文档，有哪些需要说明术语等，可以分二级标题来写，内容形式如：本文档是对XX系统第XX期项目架构设计/升级/变更进行阐述，主要从整体架构、逻辑架构、接口设计。。。等等各方面详细说明了本系统各架构维度的内容，期望读者为项目管理人员、架构管理人员、运维人员等，在编制过程中参考了XX需求书、XX架构设计规范等；评审一般会关注：    

• 文档目的及内容范围是否是从架构角度来说明的；
• 参考文档是否提到了《用户需求规格说明书》、业务知识文档等；
• 说明术语是否对非通用和非IT缩写进行了解释；
• 整章是否交代清楚了文档整体上的介绍，使读者对全篇有了大致的了解。

（二）整体架构
    描写系统在架构设计时总体的思路及方针，比如采取了分层架构、B/S架构、服务化、数据分离等，同时在设计过程中的一些约束条件，如网络访问约束、开发规范约束、开源产品协议类型等，更重要的是，作为整体架构，一定要将本系统作为一个内部不透明的整体，阐述清楚与之有交互的外部系统都有哪些，与具体外部系统的交互实现的需求是什么？如通过消息总线获取客户信息，通过企业内容管理存取非结构化数据，通过CRM获取客户信息等，并以本系统为中心描绘整个交互关系图，也就是整体架构图。评审一般会关注：  

• 设计方案表述是否清晰并与实际设计内容一致；
• 相应的约束是否真实具体，有可检查性；
• 从整体架构图是否能看清这个系统需要和哪些系统交互，交互的目的是什么；
• 对于系统间的交互是否正确，外部系统是否能满足交互，如通过CRM获取客户信息可以，获取机构信息可行吗。

（三）逻辑架构
      逻辑架构关心的是如何将系统分为不同部分以及各部分之间如何交互，其规定了软件系统由哪些逻辑元素组成以及这些逻辑元素之间的关系（层、子系统、模块等的划分决定+交互接口和交互机制[方法调用、RMI、消息]），因此逻辑架构图需要说清楚本系统包含了哪几项功能模块，模块之间如何交互，交互的目的是实现哪些业务需要。同时，对于具体的功能模块，需要详细说明清楚功能模块的业务意义。评审一般会关注：  

•  逻辑架构图是否列出了功能模块，及其模块间的交互关系；
• 是否对图中列出的模块进行了详细说明，使得读者完全了解为什么会有此功能模块，它包括了哪些业务需求。

（四）接口设计
      架构设计中对接口的设计包括两方面的内容，一方面是指本系统与外部系统之间的外部接口关系，需要全部例举所有与外部系统的接口，详细解释每一个外部接口的名称（如XX数据推送接口）、所交互的系统名称（如ODS）、交互方式（如Webservice）、交互类别（如后台异步）、接口描述（如本系统通过此接口从ODS中获取XX业务数据）；另一方面是指本系统内部功能模块之间的内部调用关系，严格意义说来说这部分属于逻辑架构的一部分，同样需要根据各功能模块的调用实际全部例举，依次解释每个内部接口的名称（如报表服务接口）、主调模块（即主动发起内部调用的功能模块如展示模块）、服务模块（即提供服务的模块，如报表模块）、接口描述（如展示模块通过此接口从报表模块获取报表数据从而实现模块间的解耦），一般来说内部接口调用属于代码级，如果对于需要独立部署的模块而使用远程调用方式的，需要做特别说明。接口是系统复杂度的一种体现，是体现高内聚、低耦合设计原则一个很重要的方面，评审一般会关注：

• 外、内部接口是否全部例举，是否按照上述对接口各维度的要素进行了解释说明；
• 对于服务方，是否确实能按照接口所描述的提供相应的服务。

（五）数据架构
      数据处理是系统的终极目标，系统在处理过程中有可能需要外部数据的协助，同时系统处理完数据后也可能需要提供给其他系统使用，因此对于数据架构最重要的是讲清楚本系统处理的数据在整个业务数据流链条上的位置，上游有哪些系统为本系统供数，下游哪些系统需要使用本系统的数据。另外，针对系统对数据的处理，需要解释系统设计了哪些关键表，数据初始化采用何种方式、数据冗余如何做，备份如何做等，评审一般会关注：

• 是否从业务数据流向角度描述清楚了本系统数据与上下游系统数据之间的关系；
• 针对本系统承载的业务处理，设计了哪些关键实体数据表及其对应，是否能全面覆盖；
• 有无本系统产生的数据体量估算、数据初始化、数据归档方式、备份策略等。

（六）技术架构
    从技术的角度描述本系统在实现过程中用到的关键技术能力，核心的技术组件，包括成熟商业套件以及开源的技术产品。如果是商业套件需要说明使用限制，升级支持等，如果是开源技术需要说明开源协议要求等。可以按分层架构的模式，比如展现层用到了JQuery、Flex之类的，逻辑控制层用到了spring、json等，这个一定是从技术上来说的，对于具体用到的组件，一定要说明组件的版本、功能、适用场景呢。当然，可复用性是技术架构的关键，无论是使用之前的组件还是开源产品，都是通过可复用性来减少资源重复投入，因此在技术组件中需要强调对可复用性的重视，评审一般会关注：

• 是否对关键技术进行了说明，且能明确表述此技术的成熟度与适用性；
• 对某些技术的使用是否与企业通用的同类技术有冲突，比如企业内其他系统多使用redis，而本系统却使用memcached；

（七）部署架构
      讲清楚系统分为了几个物理部分，每部分需要几台服务器，服务器之间是共同提供服务的集群模式还是一台提供服务一台备用的Master-Slave模式，或者是一台负责写多台多台负责读的读写分离模式，从网络层面来看，系统处于整个企业网络环境的哪个位置如外联区或DMZ区或内网区等。对于需要的服务器，需要说明服务器的软硬件配置信息，如硬件方面几核多大内存、硬盘大小、网络端口数及网络带宽要求，软件方面对操作系统的要求，版本要求，系统及软件参数的调优设置等；是否需要预安装第三方软件，所需软件的版本、部署说明等。评审一般会关注：

• 是否能从部署架构图看明白系统分几部分进行物理部署;
• 各部署部分之间的服务器的协作关系；
• 对硬件服务器的型号、配置、数量等是否明确；
• 整体部署的网络区域是否明确；
• 是否需要对相关参数的调优及特殊部署要求进行了说明。

（八）非功能性说明
      系统的非功能性包括性能、高可用、可扩展性、可维护、安全性、可移植性，一般来说，对于性能或安全性有较高要求的系统，可以将其独立成一个一级章节来写，比如实时分析类系统要求性能，交易类要求安全，可以将性能和安全作为独立的章节来描述，其他非功能性也可以类似处理。在编写过程中，可以有主次的分别进行阐述，但一定要从系统的实现性来说，即需要描述清楚系统做了何种设计或优化以满足性能，设计了何种校验机制来保障安全，如何通过集群或热备部署来保证可用性，如何讲过去状态化实现可扩展等，这些设计是如何落实在系统里的。即要从系统如何做来满足非功能性的角度，而不是解释具体的非功能性要求是什么。评审一般会关注：

• 对非功能性的描述是从系统如何实现而不是对系统的要求角度来说的；
• 每类非功能性都能从需求里面找到对应的需求点，且与业务实际相匹配；
• 系统对非功能性的实现与系统本身的架构不矛盾，架构可以通过合理的调整来满足；

非功能性的评审需要根据不同系统的业务特点来评审，总体的编制原则是说实现不说需求，毕竟架构设计是要指导后续系统建设实施的。
（九）其他说明
      此章节主要对一些辅助的约束或环境进行说明，如约束条件、风险考虑、进度要求、政策限制、环境影响等，根据实际可预见的情况编写即可。如高层对系统总体的要求、开发资源的限制、业务环境的影响、人员知识结构等。评审过程一般不关注具体事项，除非系统有特别要求。

 
      以上就是整个架构设计说明书的评审内容，也是各章节编制的指导思路，本人根据在实际工作中的一些体会粗略总结，不一定全面，但是对整个编制会有一些帮助，和大家一起讨论学习。

再次感谢原作者的精彩分享，鼓掌