这是一本正经的《设计奥义》。

我们经常在技术设计上会考虑这一点：这样的技术设计合不合理？

促使我们考虑技术设计是否合理的出发点很多，换个说法就是——评判技术设计合理性的维度有很多。

就像我们是三维世界无法理解四维世界一样，第四维到底是在三维空间之上加了空间维度还是时间维度？这一直颇受争议，但你有没有想过——万一第四维不是空间也不是时间呢？

乍一听这个质疑也挺“合理”的，但请别忘了，“维度”是由人类发明的，只是个数学模型而已，确实也存在于计算机（多维数组），但它在现实世界上并不存在，现实世界上我们已知的只存在三维，或许根本就不存在其他维度的时空，什么多世界理论、平行宇宙，全都是思想实验，从有限的经验推断而来，没有一个真正能“落地”的。

Whatever.

我们再回过头来看：“合理”本身就是一个主观的形容词（定语），怎么定义你的技术设计是合理还是不合理，取决于评判者，评判者可以同时处于多个评判维度的“叠加态”，明确了评判维度之后，才能“坍缩”成具象的评判标准。如果我们没有统一的认知，没有约定俗成的评判标准，做项目就会像时空维度难题一样，在计算机世界难以落地，毕竟，“PPT架构师”可不是个褒义词。

“设计”的结果不是薛定谔的猫，它摆在那里，你看到与看不到，不影响它的客观存在，“评判标准”就是主观产生的，由数学推理或经验总结而来。那在合理性设计的评判标准里，我们一般有什么经验可以传承或借鉴？

在这里，我给大家总结一些经验之谈。

程序员十二时辰

一问：数据一致性考虑了吗？

CAP定理告诉我们，一致性、可用性、分区容错性三者不可同时兼得，怎么记住这个特性？我们用不可能三角来理解它：

CAP原则的不可能三角

当然，这个有趣的三角形还能解释其它比较著名的定律，比如投资不可能三角——投资的三个重要维度 “流动性”、“收益”和“风险”，他们往往不能全部同时保障。

炒房就是个很好的例子，虽然房产流动性差，但风险低、收益贼高呀；又比如炒期货，高杠杆高收益，流动性好，但也伴随着高风险的存在，买了期货你就是暴富和韭菜的叠加态，永远不知道自己哪一秒变韭菜。现在投资什么最好呢？30岁之前投资自己，30岁以后说不准，但是期货就别买了（别问我怎么总结的）。

由CAP定理衍生出了BASE理论（基本可用、软状态、最终一致），可以说两者是分布式系统的基石。在实际项目研发中，系统高可用基本上由运维部门来支撑的，分区容错在设计各个微服务就已经考虑在内，而业务开发关心的更多是数据一致性，数据准不准确才是大部分开发人员需要考虑的事情。

具体是指哪方面的数据一致性呢？为什么会有数据一致性问题？

凡是涉及到网络IO、磁盘IO都会产生一致性问题。比如程序（内存）与文件（磁盘）的数据同步，各个微服务之间的数据同步等，根本原因在于内存与内存之间、内存和磁盘之间、各个网络服务之间存在区域边界划分（粒度不同）。计算机的两个区域可不像两个纠缠的量子一样能同时发生变化，计算机的乐高世界是0和1，是集成电子电路，基本通讯单位是电子。数据会受到各个交换机之间通讯的影响、内外存交换时序的影响、CPU运算时差的影响等等，我们要解决的是数据在各种粒度分区下的通讯问题，所谓数据同步的“强一致”，在更细粒度的范围还是会失效。

二问：隔离性怎么样，边界是否清晰？

思考一下，计算机为什么要刻意把内存和磁盘两个区域划分开来？内存使用磁盘的空间，不是能加载更多程序吗？

之所以把它们划分隔离开来，是因为设计之初就考虑把它们用于解决不同的问题——内存的数据需要快速存取，磁盘的数据需要持久稳定，内存是计算机的工作场所，磁盘用来存放暂时不用的信息。内存是CPU和硬盘数据之间的缓冲，CPU只能读取内存里的数据。从单一职责上看，它们各自负责各自的工作范畴，互不干涉而又紧密连接。

以小看大，我们在实际项目开发中是怎么做隔离的呢——跨库表与表之间使用表/字段冗余隔离、领域模型使用边界上下文隔离、不同的业务聚合使用微服务隔离、服务内部与feign之间使用防腐层隔离等等……这是一种对内高内聚、对外低耦合的设计、一种“变化”与“不变”的博弈。

任何一个事物都应该有清晰的边界，当边界不清晰的时候，我们就需要考虑把它们给轮廓化，少一些模糊地带，明确职责以后，也有利于团队协作与组织管理。

三问：扩展性怎么样，能否快速拥抱业务变化？

扩展性考虑的是抽象能力，在PRD分析的时候，要考虑到哪些数据模型、哪些表、哪些字段后续可能会扩展的，反复与产品经理确认，评估一下需要抽象到什么程度。

举个简单的例子，比如一张表既要保存销售订单也要保存售后订单，如果用一个字段存销售单号进行关联，另一个字段存售后单号进行关联，万一以后再加一个采购单等等各种单，就需要重新加一个采购单号的字段……这时我们在设计之初就要考虑清楚，以后会不会有别的类型的订单，如果有，就抽象成单据类型+业务单号来表示。

对于明确不会扩展的部分也不需要过于抽象，抽象也不一定总比具象优，还是要根据实际业务场景来评判。

四问：业务时序正确吗？

有很多时候我们时序图，是为了搞懂业务时序、系统操作时序，避免出现期望的步骤执行颠倒产生的时序逻辑错误。

举个简单的例子，在订单中心异步调用支付中心创建某条记录，随即在同一个线程内又同步调用支付中心操作这条记录。如果异步线程无法在主线程后续操作这条数据之前完成数据创建，就会发生时序错误。在流程复杂的情况下，同步异步各种流程穿插在一起，就特别容易出错。

这就需要考验逻辑是否缜密了，数据什么时候该生成，什么时候该操作，什么时候该归档或销毁，把数据模型的生命周期给管理起来，用户和各个模型之间的生命周期是如何关联起来的，想明白就不难了。

五问：高并发场景扛得住吗？

开发之前我们经常会考虑一些实际业务场景：这个功能是给谁用的，会有多少人同时使用？实际上我们考虑的是高并发场景。

高并发的本质是什么？它的瓶颈在哪里呢？怎么评判合理范围？

高并发指的是高并发读写，一般用于评判系统对数据的吞吐能力、处理能力，当有大量的读写请求过来的时候，系统能不能接得住这些流量。

• 如果是读多写少，是不是要考虑在内存预加载磁盘数据，使用缓存，提高读IO速度；
• 如果是写多读少，是不是要保证写入顺序，防止并发问题，能不能批量写入，减少写IO次数。

了解了底层逻辑以后，评判合理范围就变成简单的数学问题了，先分析资源瓶颈在CPU、IO、还是内存等等，通过算式可得：峰值资源瓶颈=单位平均资源*峰值数量。

当单机的CPU、IO利用率已经最大化，还是不能满足实际业务场景，这时就多机扩展并行处理业务流量，或者引入一些中间件来实现“削峰填谷”、“熔断降级”，最终实现高并发、高性能、高扩展的新“三高”设计。

从这个层面上讲，架构设计实际上也是一种管理活动，只是架构师们在这里管理的不是人，而是计算机资源，包括CPU、内存、磁盘IO、网络IO等，把计算机资源有效地组织管理起来即可。

架构师需要考虑的事情很多，数据一致性、隔离性、扩展性、高并发等等，这只是评判业务设计、架构设计的几个常用维度，我们需要做的就是不断总结并应用于实际问题上。

怎么把一些好的思维方式方法与实际问题关联起来呢？分享一个好方法给你——

当你学习到一个新的思维方式方法的时候，先把它用思维导图记下来，然后把3个已知的问题与之关联起来；当你遇到问题的时候，把它记录下来，然后调用你的一个思维方式与之关联。久而久之，咱们解决问题与思维方式的关联性就越来越强，处理问题不再靠过去的经验，而是使用科学高效的思维方式方法来解决，不断给自己筑建“元能力（Meta capability）”的壁垒。

技术思维与管理思维一样，存在普适性，所以我们不讲特殊，我们只有真正掌握那些“不变”的东西，把那些“变化”的事情固化成流程（升维的过程），才能在工作中，为企业“降本增效”。

这篇听起来可能有点“PPT”的味道，先当个“PPT架构师”也未尝不可，现在创业公司先卖PPT解决方案的就不在少数，前提是画的饼够不够大、有没有人愿意听，成长的路上总会有“眼高手低”的过程。

所以，有时候适当抽象概括一些概念也挺好的，时常给自己的思维充充电。

就好比——“设计合不合理”可以抽象成“设计的合理性”，“能否快速拥抱业务变化”可以概括成“业务扩展性”，你说“看完点了个赞”能不能提高我的“分享积极性”？

老规矩，一键三连，日进两千，点赞在看，年薪百万！