万剑归宗—架构设计中的抽象思维与具象思维

新项目上线,用户量不断增加,工作中继续不断发现问题,解决问题。花一点时间来总结一下自己对架构设计的理解。

小小的打个广告。这篇文章是发布在neil的微信公众号上。neil的文章都会第一时间发布在微信公众号上。欢迎小伙伴们关注。

微信公众号:互联网与作曲家

  • 武侠小说中的“万剑归宗”----极致的抽象思维

一点题外话。自己从小就是武侠迷,金庸古龙的经典作品都看过很多遍。最喜欢的女主,是《倚天屠龙记》中的赵敏:敢爱敢恨,邵敏郡主。其扮演者黎姿,是我心目中两位女神之一,性格与赵敏非常相似。另一位女神是周慧敏。最喜欢的男主,当属杨过:杨康之子,“有过则改之”,曾经年少轻狂;洗尽铅华之后,神雕大侠悟出黯然销魂掌,力挽狂澜。

武侠小说中,武功的最高境界都是“无招胜有招”,一切有具象的招式都是下乘。到了这种境界,草木皆可伤人。金庸小说中描写剑魔独孤求败,其武功修为有四个阶段。第四个阶段臻至化境,“四十岁之后不滞于物,草木竹石均可为剑。自此精进,渐入无剑胜有剑之境。” 从利剑,到软剑,再到无锋重剑,最后是草木竹石皆可为剑,其实就是一个将具体事物不断抽象的过程。最开始时,武功需要用剑的锋利去展现;接着变成只需要软剑;然后连剑刃也不需要了,重剑无锋,大巧不工;达到最高境界后,掌握了武力的真谛,可以将武功通过任何形式展现出来,“无剑胜有剑”。类比到架构设计上来,从最开始的C语言输出hello world, 到执着于“PHP是不是最好的语言”,再到对各种设计模式,架构思维了如指掌,最高境界就是能够应对任何复杂的业务需求,将架构设计做得像艺术品一样。什么时候能达到这种境界啊。流着口水YY中......

  • 看山是山,看山不是山,看山还是山

宋代禅宗大师青原行思提出参禅的三重境界:参禅之初,看山是山,看水是水;禅有悟时,看山不是山,看水不是水;禅中彻悟,看山仍然山,看水仍然是水。直白一点就是说:人之初,性本善,大家刚开始的时候都是一张白纸,都很单纯,即,看山是山;随着阅历逐渐丰富,经历过一些沧桑后,感觉这个世界太艰难了,累觉不爱,看水不是水;心态继续蜕变,返璞归真后,重新以单纯的角度来看待这个世界,顿悟,看山仍然是山,看水仍然是水。这是这三重境界的本意。

这句禅语还可以用于抽象思维与具象思维的联系。“看山是山”,即分析具体问题;“看山不是山”,就是将具体的问题进行提炼,抽象,形成一套架构设计和解决方案,可以适用于所有类似的具体问题;“看山还是山”,就是一个验证解决方案的过程。将抽象出的架构用于解决具体的问题,根据效果来不断改进,优化原有的设计。这是一个从具象思维到抽象思维再回到具象思维的过程,我认为任何架构的设计都是基本符合这个过程的,抽象分析和具体分析,二者缺一不可。举个工作中的例子:同事A针对一个问题设计出了两套解决方案,这两套方案本身是完全对立的,而且由于问题的复杂性,两套方案都无法完美解决问题,需要评估各自的效果。同事A仅仅从抽象的理论上分析,两套方案的效果是一样的。但实际情况却是:因为不同位置的曝光率不同,会导致两套方案的效果出现极大的差距。可以简单总结下:抽象理论分析与具体问题分析都需要进行,并且二者的效果是互补的。

  • 大道至简

大道至简,国外叫做奥卡姆剃刀原理,即解决方案应该趋于简单而不是趋于复杂。这个原则说起来容易,做起来却无比艰难。软件工程的问题越来越复杂,没有办法依赖简单的答案来解决。提一下“没有银弹”这篇经典的论文。该论文讨论了次要复杂度和必要复杂度。次要复杂度是指由人们本身所产生的问题,比如使用C++,java还是python. 这类问题是可以被比较快速地解决的。必要复杂度是指软件本身要解决的问题,比如复杂的业务场景,海量用户访问等等。设计模式有很多种,但没有一种是万能的。从复杂的问题中提取要点,不断进行抽象,再结合具体问题进行分析,在保证满足业务需求的前提下,尽可能地简化方案,优化方案,再考虑到未来可能变化的业务场景,避免过度设计。这大概就是架构师的功力所在了吧。

  • 架构设计中的二八原则

二八原则适用于很多地方:20%的时间完成80%的工作,剩下20%的工作可能需要80%的时间才能完成。架构设计中需要考虑到各种异常情况的处理,很多时候异常情况的处理才是最花费时间的。但我认为异常处理可能是非常关键的。我们花20%时间完成了80%的工作,同样的,竞争对手也可以在很短的时间内完成80%的工作。那么,最后20%就是我们的可能的优势所在。好的用户体验,不只是让用户用得舒服,还需要不会让用户感到不舒服。那么,对异常情况的处理,可能正是保证体验的关键所在。

  • 最近用到的架构思想
  1. 配置化 配置化带来高度灵活性
  2. 模块解耦合 每个模块只做一件事,保持单纯
  3. 读写分离 提高性能的关键
  4. cache 离业务层越近,cache命中程度越高,但可复用性越低
  5. 读写一致性 海量服务优先保证性能,会故意损失一部分实时的数据一致性,但会绝对保证最终数据是一致的

今日荐歌:

《Over My Head》Sum 41

《真正Hip Hop》 欧阳靖

《老伴》 李荣浩

本文章欢迎转载,转载请注明微信公众号和作者。微信公众号:互联网与作曲家. 作者:neil 版权所有,翻版必究!

时间: 2024-10-16 21:59:12

万剑归宗—架构设计中的抽象思维与具象思维的相关文章

架构设计中服务层的简单理解

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 在ddd设计中我们经常会提到服务层,服务层是什么?职责是什么?有什么好处?. 先看简单的层次图(注:这里并没有考虑其他多余的领域逻辑数据层存储,或者UOW这些细节) 我的理解是服务层是处于我的应用程序业务层和表现层之间的应用程序边界,边界可能是很薄的一层类设计或者是分布式服务网络跃点.它是一个与技术无关的名词.由表现层直接调用,契约,执行命令(修改状态(CUD))或者是查询返回dto(数据迁

架构设计中的6种常见安全误区

[架构源码地址] 自然世界中,先天有缺陷的生物总是容易被细菌病毒入侵,而健壮的生物更能抵抗细菌病毒的攻击,计算机系统也是一样,若有先天的架构设计安全缺陷,那么在面临网络攻击的时候,就更容易被入侵或者破坏,甚至因为设计架构的原因,有些漏洞完全没有办法修复!本文将讲述架构设计中需要避免出现的安全误区,以帮助我们研发人员设计出更安全健壮的软件架构.本文的举例既有硬件架构,也有软件架构,还有基础架构等等不同的架构,但其中原理适用于所有的架构设计.下文将从兼容性设计误区,降低成本设计误区,数据和代码不分离

挖财首席架构师王福强:架构设计中的6大关键点

编者按:要开发出用户满意的软件并不是件容易的事,软件架构师必须全面把握各种各样的需求.权衡需求之间有可能的矛盾之处,分门别类地将不同需求一一满足.在UPYUN Open Talk 第二期"移动时代互联网金融架构趋势"的技术分享中,挖财首席架构师王福强带来了<挖财的互联网金融技术探索>,王福强重点分享了当前挖财架构设计中的6大关键点: 1. 系统层级分离 从大的体系来讲,挖财主要在做四个纬度的事情,第一个是会员中心,挖财有一套自己的会员体系,第二个是现金流,第三个是风控中心,

看懂架构设计中的服务隔离

前言 我们在做系统架构设计的时候,经常离不开的一个话题就是进行服务的隔离设计. 那什么是「服务隔离」呢? 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖.当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其它模块,不影响整体的系统服务. 其实隔离设计并非软件行业独创,它是借鉴于造船行业.行业有一个专业术语叫做「舱壁隔离」.利用舱壁将不同的船舱隔离起来,如果某一个船舱进了水,那么就可以立即封闭舱门,形成舱壁隔离,只损失那一个船舱,其他船

web系统架构设计中需要知道的点(前端篇)

上周没写东西,这周写点互联网系统开发中需要了解的技术点,每个点都可以发散出去,连接更多的知识点,打算做个逐步细化的记录. 一个应用的整个生命周期中(生,老,病,死)都需要有一个整体规划. 前期 评估需求,根据需求提炼出其中隐含的非功能性要求,做为容量评估的参考.一般就是大致估算一下,技术发展到现在,如果是聊天或游戏应用,随便一个服务器单机能能维持100W-160W左右的tcp长连接并进行通讯.所以普通的创业起步阶段的应用一般不必太担心设计问题,可以等业务量慢慢上来慢慢调整系统架构. 互联网上许多

架构设计中常见的语义耦合类型的总结

语义耦合是隐性的,不易察觉的耦合类型 ,是导致代码重构.调试.修改复杂度急剧增加的主要原因. 1,操作顺序耦合 使用一个对象,需要先调用Init(),之后才能调用DoAnything().这种顺序耦合,即使在文档中remark也是极为不优雅的做法. 2,全局参数传递 模块A修改了某个全局参数g_val,模块B读取该值.模块B必须知道模块A已经对该参数赋值. 3,业务封装不够紧密 模块A向模块B传一个参数,模块B根据该参数选择对应的操作.模块A必须知道与业务相关的所有的操作类型.对于模块A,仅传递

解构在架构设计中的运用

通过解构主义的视角来拍摄的电影极具新意,令人眼前一亮,令传统的故事多了很多创新 软件架构也是在前人的基础上做设计,那么借鉴解构主义能够产生很创新的方式来实现内容的 获得,有新意而不是做个轮子去解决现有问题或新的问题. 待续...

系统架构设计中缓存的重要性

在分布式网络系统中,缓存更是无处不在:(1)对静态页面的缓存:(2)服务端对某些请求数据的缓存(包括本地缓存和分布式缓存):(3)客户端对服务器端数据的缓存,例如我们的头像等信息: 使用缓存带来的问题: 缓存何时写入? 缓存如何失效? 缓存和DB的一致性如何保证? 多级缓存有什么最佳实践? 如何避免缓存穿透问题? 缓存穿透: 我们在项目中使用缓存通常都是先检查缓存中是否存在,如果存在直接返回缓存内容,如果不存在就直接查询数据库然后再缓存查询结果返回.这个时候如果我们查询的某一个数据在缓存中一直不

谈架构设计中DDD思想的运用

首先,描述一下我的业务场景及项目分层结构,非标准DDD(其实我不觉得有标准),只是思考的时候有带入DDD思想. 业务场景:这是一个ERP系统对中台提供的接口项目,仓储操作大多都是存储过程去完成的. 项目结构,如图: WebAPI层:这个不用多说了,入口. DTO层:增加数据传入传出对象,和领域model.实体model区分.(要不要围绕领域model或从现有系统中提取领域model看实际业务情况,拿我目前这个项目来说,得不偿失.) Services层:业务服务层(可以命名成BizServices