架构是一个动词，还是一个名词？可以组合的词汇有：架构设计、架构师，我认为，架构是动态的，演进的。词典中是这样解释架构的，人们对一个结构内的元素及元素间关系的一种主观映射的产物。也可指构筑，建造。
我理解架构本身不仅仅是指这个结果（成品），同时架构亦可以理解为建造的过程。

架构是一种思维模式。架构师是一个title。为什么说架构是一种思维模式呢，小到一个模块，大到一个平台，高内聚低耦合、隔离、层次、开放、扩展、自治等等都是一样的，无非是包含的单元有大有小而已。下边列的几条，是有关文章对架构作用的归纳。

[]软件架构能够满足系统的品质[/][]架构设计使受益人达成一致的目标[/][]架构设计能够支持计划编制过程[/][]架构设计对系统开发的指导性[/][]架构设计能够有效地管理复杂性[/][]架构设计为复用奠定了基础[/][]架构设计能够降低维护费用[/][]架构设计能够支持冲突分析[/]

 诚然，架构设计可以起到这些作用，但是 这些作用之间的连接是什么？ 这些表述看起来都是对的，但是 如何系统化的看这8个维度呢？

项目或者产品研发过程中有系统分析文档，概要设计等，而这些文档都是有模板可以遵循，模板这个东西很奇怪，赞的地方是依照葫芦画瓢不至于太难看，不好的地方是如何体系多个目标或者多维度诉求的达成？

我们在谈架构是什么，理想中的架构该是多么美好，市面上有关架构的书籍有： 面向模式的软件架构、程序员必读之软件架构、企业应用架构模式、 一线架构师实践指南等等。有一些是方法论，有些是案例集、有些讲架构师的素质。

但是，具体要如何做？

以终为始的架构设计

基于我从业的所见所闻所感，我提出的一个明确观点是以终为始的架构设计。
什么叫以终为始呢，就是 满足或者引导客户价值的挖掘和表达。


上图是一个非常著名的图，我们一般拿它说需求变形的事情。
架构设计作为统领全局的方法体系，自然要贯彻始终的最好需求的真实反映、衡量标准的提炼（SLA）、端到端的运行处理、业务运营能力来支撑目标架构的实现，从而支撑当下需求和为远期需求发展做好可能的准备。
请容许我用黄金圈理论：why-what-how的线索来叙述一下。


我的观点切分了3个维度，why-how-what，11个观点。
1、为什么要做架构（WHY）


如果说设计师给你的效果图=UI设计的话，那么建筑工人建造的就是设计的骨架了[分层、部署]，而合适的架构可以见微知著，适应变化，在快速规模化效应到来时较好的解决客户问题。比如如下图的2个例子：


帆船发展到船身的扩大，内部设施的变化;传统的电商模式，营销方式是打折、满减、包邮、满返；而线下业务比如肯德基又衍生了第二件半价，第三件又如何！
总结一下：

[]没有设计师的蓝图无法建造房屋[/][]快速规模化、适应变化、解决客户问题[/]

2、如何做架构（HOW）
 
以终为始，不忘初心。
 
帆船发展到船身的扩大，内部设施的变化;传统的电商模式，营销方式是打折、满减、包邮、满返；而线下业务比如肯德基又衍生了第二件半价，第三件又如何！

初心是什么，就是用户的本质需求。用户想要什么就给什么未必是本质需求，比如张三问你要面包，你无法提供，但是他的本质可能是因为他饿了。

在一些公司，往往会出现下面的情况:


上图所示的一些现象就是因为做设计可能忘掉了初心，导致技术膨胀。

我们再来看一个例子，如下图：


不论系统如何组织，用户最关心的是响应时间(ResponseTime)，和展示金额对不对。所以在一开始设计的时候要考虑如何取得用户的2个关注要素，正确性和体验。是否考虑链路级的监控，链路级的关键数据校验，规则如果分散到多个系统，如何检查整体组合命中的情况等，都在考虑之列；链路上每个系统的容量和响应时间等。PMC框架，什么是PMC框架呢？

平台型的产品都有这3端的考量。比如，天猫、Uber、O2O的App。如下图：


 
滴滴或者Uber解决出行的问题，电商解决网上购买商品的问题。平台的本质设计是符合用户侧、商户侧、平台侧的3端诉求的。比如电商的IM解决信息沟通，客服解决售后，还有其它方式解决可能的作弊，交易、安全、评价体系等一系列的问题。

Uber也是基于交易，乘客付款给司机，但是对于用户而言是更快更省的叫到车，司机的信用评价沿用了星级评价，投诉等保障措施，但对于基于地理位置的撮合（用户的地点，划定一个圈寻找可以承载他的车包括允许共享座位的车）是其核心，也是Uber孵化出dispatch模块的原因。

有意思的事情发生了，Uber老板一觉醒来发现他创造的不仅仅是一家出行公司。


司机和车只是它的资源，供应方（supply）可以是一家蛋糕店、鲜花店或者是西湖的休闲船只管理中心，那么它以下能力可以复用：

[]调度能力[/][]用户呼叫的界面、策略[/][]地理位置处理[/][]交易事后处理等[/]

大部分变化在于运送的物品（属性）以及一些附属需求，而这些都是可以通过良好的平台设计+可扩展的新市场产品特性来完成。

架构非单一视角，单一层次

架构的多层次多视角有助于厘清本质，对问题域更好求解。
以一个第三方支付的应用为例，就有诸多的考量因素。比如风控、比如营销、比如签约（签约的顺畅度）等。


按业务执行、业务运营等视角又可以加以组合，组合有什么用呢，用来考量设计的要素（谁为谁服务）。


比如营销是业务运营板块，为了更好的业务执行的。Uber的打折优惠也好，拼车免费也好，都是不影响主流程的，且为了进一步刺激消费；然而有的产品把营销活动设计的极其生硬，极其难用，相当于把一件大人的衣服穿到了一个小朋友身上。
再举一个例子，体验和服务，我在想存在一种可能的设计，比如新上一个产品，考虑可能带来的服务量（在线客服、热线客服、帮助等），当实际操作一定比例的时候，强烈预警产品应该优化，并能分析出优化之所在。可能一开始数据线拍的不准，但是不断训练和尝试，则能形成正循环。一个不恰当的KPI就是服务的目标是降低来电，减少二次来电，但产品不断野蛮生长，最后也就是一个然并卵的问题了。
PS：前一阵了解，在百度，通过快速构建MVP然后通过舆情信息的收集不断优化产品迭代就是一种蛮有意思的尝试，业务运营一定要为业务执行（产品）服务。聚焦SLA

[]避免关注枝节遗忘全局[/][]避免关注自身忘却出发点[/]

前面阐述了以客户价值出发构建架构，同时考虑C（客户侧）、P（平台侧）、M（商户侧）的不同诉求。那么如何衡量这些成效达到了呢？这需要清晰明确地设定SLA。下面以12306为例。

12306经历了02年的阻塞、中间间或的宕机、到与黄牛（抢票软件等）斗智斗勇开启了杀伤力巨大的图片校验码而引发众多吐槽。那么12306对客户带来的价值是什么呢？首先要尽量多的人买到票（票的数量受制于运输能力），比较顺畅的拿到票（有人搞了几天也没抢到），公平性（开发抢票软件的浏览器是不是应该治理，还有哪些抢票的地下软件）。

有专家说12306不要把图片校验码搞复杂，对抗黄牛不是他的主要职责。我认为只说对了一半呢，防作弊是它要做的事情，因为为了客户价值达成。

当有报道12306图片识别困难，则铁道部有回应，能买到票就不错了，则显得对价值的识别又low了，票终会卖完（这2年系统不宕了），票以什么方式卖完，大部分人购买的顺畅体验也是非常重要的。

新华社12月8日发表时评《12306验证码究竟打败了谁？》，文章说，面对消费者的质疑，铁路部门不及时回应群众关切，不作出解释，也不针对问题修改验证码设置，这种冷处理的确令人费解。铁路部门还需增强意识和技术手段，摒弃一家独大的“傲慢思维”，从改进验证码这种细节抓起，多麻烦自己、少难为群众，通过体制机制的创新，让群众出行更方便。

说了这些，大家不妨就梳理一下实现客户满意可以用的招，比如是不是搞预约，预约才有资格买票（且7*12小时分批），避免拥堵（非通知取票时段）你去刷也没用。再比如运行程序如何区分来的是普通用户还是刷单软件，采取不同的策略对待，这里肯定有不少事情可以做，而不是一图难天下。

看完12306，再来看一个第三方支付的例子。


业务运行（支付业务），涉及到用户下单、形成交易并支付等相关处理。而用户很关注我能不能快速把钱正确安全的付掉。为了求证付款正确性，他们也会习惯性在第一时间查询消费记录。

可能有人问了解SLA要求，和具体设计存在哪些关联呢？仍以上图为例，我们可以做一系列假设做恰当的预设计。


比如从系统运行角度看，如何度量用户SLA（体验的顺畅度，支付成功率）以及更多行为数据（用户在哪一步流失的，什么原因），从下单到完成支付的花费时间是多少等。

要做这些，就需要全链路的监控，进而推之需要做统一的上下文，事件码来串联请求的链路（traceId技术语义，业务语义则可能是userId）。

再举个例子。在数据量100万级可能通过buyerId或者sellerId为查询条件分别满足按买家、商家不同的维度查询消费记录。当数据规模扩大之后，可能通过数据库表的拆分来做sharding。则涉及到key选取的问题，该问题就是比较典型的多维度查询问题。抽象、协作、扩展、复用
抽象、扩展人人都知道，但是如何识别本质并不做BDUF（Big design up front）并不容易。以Uber为例，Uber定位已不仅仅是一家出行公司，利用其物流能力可以叫飞机，叫外卖，包括送花。


要知道Uber也不是一天炼成的。有文章披露，旧系统是为专用客车运输所设计的，做了很多假设：每个车辆一个乘客，不适用 Uber Pool（拼车服务）。运送人的想法深深嵌入到数据模型和接口里。这样限制了扩展到新的市场和产品上，比如运送食物和箱子。最初的版本是按城市划分的。对于可扩展性而言是好的，因为每个城市可以独自运营。但当越来越多的城市加入，这变得越来越难以管理。城市有大有小，负载也不一样。后来，他们重构了dispatch模块，让调度的接口不依赖具体的专用客车的领域而具备可扩展性，并通过微服务来做切分和管理。


 
从全局视图分析，一言胜千言


 
这是一个典型的应用系统设计模板，其中标准了几类典型容易产生资金损失的模式。比如幂等性问题，并发问题，接口返回码定义问题等。一张图就表示清楚设计的注意事项。3、架构是什么（What）架构兼具组成和决策特点，架构之于架构是自包含关系。



架构派别之争都有部分道理，组成和决策兼而有之。架构是演进出来的
架构是演进出来的，架构是动态的。下图为一个架构演进视图的举例说明:


11年我们有一个不太成功的示范，就是自信试水型业务一点会爆发，在产品层之下设计了一个基础层，做核心领域的沉淀，后来孵化了10+几个小产品，结果核心的2张表被玩坏了。完全烟囱型模型+plugin（or工具黏合剂）可能更合适。无纯粹的非功能特性
区分功能与非功能，容易把后者当作增强性要素。
下图为某平台的能力视图，容量，高可用能力，高性能都是和外部平台的要求匹配的


再以下图为例，所有的特性都可以关联到用户体验和功能上。

具体

有人说我都看完了，但是我自己还是不知道如何干? 那就再帮帮你：

[]请度量你的产品对于用户、商户的SLA（接入效率、接入成本、用户体验、稳定性、应急处理能力等）[/][]适当的时候考虑链路级业务监控视图[/][]在系统链路调用上加上traceid这样的东东[/][]考虑平台沉淀能力时考虑业务形态的扩展，比如uber只是一家解决出行的公司么？[/][]在不同阶段采用不同架构，试水期说不定演烟囱型架构是最适合的，因为短期的价值是打一个点（业务上），让自己活下去（平台方）[/][]非功能要素不是加分项，可能是主体价值体现点，比如商户需要一个批量导入接口，你提供了单笔处理接口，然并卵！[/][]非功能要素融入到日常研发中，比如微软的同学分享office某个迭代性能慢了，就是P1级故障，其背后必须得有日常性能的回归环境才行。[/]

再次总结一下我的观点——

3个层次、11个观点、一句话（以终为始）！


本文转自：老于聊架构1
作者：于君泽