这是一本正经的《设计奥义》。
我们经常在技术设计上会考虑这一点:这样的技术设计合不合理?
促使我们考虑技术设计是否合理的出发点很多,换个说法就是——评判技术设计合理性的维度有很多。
就像我们是三维世界无法理解四维世界一样,第四维到底是在三维空间之上加了空间维度还是时间维度?这一直颇受争议,但你有没有想过——万一第四维不是空间也不是时间呢?
乍一听这个质疑也挺“合理”的,但请别忘了,“维度”是由人类发明的,只是个数学模型而已,确实也存在于计算机(多维数组),但它在现实世界上并不存在,现实世界上我们已知的只存在三维,或许根本就不存在其他维度的时空,什么多世界理论、平行宇宙,全都是思想实验,从有限的经验推断而来,没有一个真正能“落地”的。
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解决方案的就不在少数,前提是画的饼够不够大、有没有人愿意听,成长的路上总会有“眼高手低”的过程。
所以,有时候适当抽象概括一些概念也挺好的,时常给自己的思维充充电。
就好比——“设计合不合理”可以抽象成“设计的合理性”,“能否快速拥抱业务变化”可以概括成“业务扩展性”,你说“看完点了个赞”能不能提高我的“分享积极性”?
老规矩,一键三连,日进两千,点赞在看,年薪百万!
关于作者:
我叫Jensen,某C端分销平台合伙人,运营上千个优惠券分销社群。目前在广州某B端垂直电商互联网公司就职架构师岗位,运营公司的技术公众号、个人公众号《架构师修行录》。“不懂产品的技术不是好的架构师”——用产品思维、架构思维解决复杂业务问题。