架构师必备逻辑思维(上)

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 架构师必备逻辑思维(上)

4 

推理模式-架构师必备逻辑思维


   我们认识世界的过程中,潜意识或有意的运用大量的推理。推理就是从一个或几个已知判断推导出一个新判断的思维形式。任何推理都包括:推理依据的已知判断(前提)和推出的新判断(结论)。推理的几种方式:类比法、归纳法、演绎法、归因法。我们在工作、演讲、取舍、决策...时,无数次的应用了这些推理模式,但是我们可能当成常识来理解,反而忽略人类如何有此类能力。


    我们掌握了推理的原理,会优化我们推理的过程,更加“客观”的认识这个世界。甚至我们学的的目的,就是为了增加推理前提的宽度(更多领域)和深度(更准确)。具体网上搜索了解,这里举例说明一下:


l类比推理法:物以类聚人以群分    类比推理是两个对象在一系列属性上相同,而且已知其中一个对象的还具有其他属性,由此推断另一个对象也具有同样属性的推理。它不是一种证明,用于探索新思路、新发现的一种观点和手段。


1、鲁班类比带齿的草叶和蝗虫的牙齿,发明了锯;2、人类仿照鱼类的外观和它们在水中沉浮的原理,发明了潜水艇;3、设计模式的概念最早起源于建筑设计大师Alexander的《建筑的永恒方法》一书,尽管Alexander的著作是针对建筑领域的,但他的观点实际上适用于所有的工程设计领域,其中也包括软件设计领域。在《建筑的永恒方法》一书中,Alexander是这样描述模式的:模式是一条由三个部分组成的通用规则:它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题,以及该问题解决方案的核心设计。


l归纳、总结法,看啊看的就找到规律了:


1、每天开车回家,发现连续好几个周五晚上,回家时间比平时晚半小时。

2、总结个规律,发现周五晚上高峰期确实比平时堵。

3、倘若周五有赶飞机等急事,需要提前预备半小时时间。


4、如果周五赶飞机遇到下雨呢?

5、如果春节期间北京的周五呢?... ...         归纳推理又分为完全归纳推理和不完全归纳推理。着重你看到的是否足够多(样本足够多),你总结的规律能否拟合此类现象(样本的好坏),你想找的规律是否称之为规律(模型假设是否合适)。


如果了解机器学习的原理,这些很好理解。 个人建议大数据时代,对数据sense要积极建立,不能像父辈或没文化人一样一样,看到几篇赞扬祖国文章就觉得祖国一片美好;看到几篇诋毁祖国文章,就觉得满眼都垃圾。(真心期望推荐系统更加智能一些)。针对架构师,见过或经历过很多案例,可以采用类比法,然后归纳总结推理。不能拿一年的经验工作十年;而是工作十年,至少积累十年的经验。这样才有可能爆发出、演绎出更多的经验,不担心技术更新、行业更新。


l演绎推理法:(大前提、小前提、结论)三段论:


1、大前提:redis发布版本中自带了redis-benchmark性能测试工具,可以使用它计算qps。假如我使用50个并发连接,发出100000个请求,每个请求的数据为2kb,测试4核8G机器redis服务器性能,测试结果每秒44150.11个请求,既QPS4.4万。


2、小前提:现在有个场景,50并发,每个请求1.5kb左右,场景支持并发多少,需要配置什么型号机器。


3、结论:4核8G机器,可以支持4万并发。      


 如上所示,演绎法需要积累或学习很多大前提,以及大前提需要满足的各项指标。当遇到问题时,能框进大前提里,结论很容易得出,并且通常是正确的。


 1、日常我们需要对mysql、es、mangodb、redis、消息队列、tomcat、nigix、netty、java、go等中间件或语言有相关的认识;当然也需要对常见的系统架构有这种规律性认识。比如:广告架构、搜索架构、推荐架构、交易架构、秒杀架构、log架构、监控架构... ...有规律性认识。构建自己的大前提库。


2、当需要构建系统,比如秒杀功能场景时,能够快速确定当前小前提(应用场景)归属哪个或哪几个大前提


3、这样可以快速组合得到一些结论,做一些调整,作出响应。不能遇到新的业务需求,从头开始学习、实现。


l归因推理法:


   也叫溯因推理,是寻找最佳解释的过程。    架构师在排查系统问题、性能瓶颈是常用,需要配合测试、日志等手段一起使用。也是俗称的解决问题能力。通过溯因方法解决系统的问题,是在丰富的知识矩阵基础上展开的。例如基于机器学习的广告点击率的预测、基于协同过滤的推荐系统,通过归因设计出更加有效率的反馈系统,不断地优化算法、调整特征数据。随着神经网络、深度学习的发展,很多不能解释的系统出现,只能通过事后数据验证来判别优劣,构成一个更大的溯因循环链(这也是现代产品必备的基本要素)。


   总之,从业者需要把自己的经历、见到的案例能够形成自己的知识体系,当遇到问题是,选择合适的方式解决问题。如果不能形成对“世界”的认知体系,穷尽终生也学不玩的知识,也会有学不完的困惑。


   注:把对架构过程中常见关键术语解释一下,便于我们面对新技术时,能够迅速掌握个大概。


1、设计模式:类似问题较为通用标准的解决方式,前人把遇到的细颗粒度问题分门别类阐述,形成的标准解决方案


2、架构:跟设计模式有点类似,视角更高、解决的问题更宏观一些。


3、组件:组件作为构造软件的“零部件”。供应用开发人员在构造应用系统时选用。


4、框架:框架是为了解决特定问题而存在的,但只能解决通用部分,留些口子让使用者完成。诸如模板框架、缓存框架、MVC框架、ORMapping等,框架不能直接使用,需要二次开发。比如:spark、flink框架预留了很多接口或钩子,需要应用开发人员在算子基础上,定制自己的应用,而流计算、批计算归类为设计模式或架构。需要开发人员干的事情少而简单的框架就是优秀的框架,如springboot。


5、平台:平台的概念类似框架,但又结合的架构的考虑,它是更高层面上的“框架”,准确说是一种应用。这里跟技术本身关系不是太大,是应用级别。


6、中台:如果几百个字说不清楚这个概念,那么就不是技术圈的概念。个人觉得不应该由技术从业者解释,越解释越乱的感觉。


7、中间件:从更高的层次看,类似于组件。是解决某类问题,可独立运行的应用。如:解决各类存储问题的数据库中间件,解决消息传递问题的消息中渐渐,解决web服务的中间件框架(tomcat其实也算框架)。


8、工具:个人框架、架构、中间件都带有工具的属性。造成it从业者被工具困扰太久太久,以至于对一些底层逻辑理解偏差,太专注工具的使用,而对工具形成的初衷不了解。而工具、轮子也是从业者喜好之处,形成死循环。




5 

锤子VS钉子---寻找大锤子VS制造大锤子



   孔子在论语中说到”君子不器”,我们不能把自己的身份、技能、做事方法等固化,甚至我们有必要刻意的摆脱自己头上固有的标签。假如我们把经历的眼见的现象案例称之为经验,归纳后变为规律,基于规律我们制造的、用顺手的工具称之为“”。显而易见,“”能解决的问题是规律能覆盖的现象,但是规律也可能有不适用的时候。    我们不能像圣人一样留下永恒的“道”,只能不断的发明轮子、工具,期望留下一些痕迹。按照心理学来讲,人们总想证明自己的理论是正确的,说不服别人,就制作出一个工具来证实能够提升多少效率。这个事情没有任何问题,只是这类东西太多了,造成两个不好影响:第一、太多了,选择困难。第二、太好用,成了工具的奴隶。    有人说过,如果你手里有一把锤子,所有东西看上去都像钉子。还有一位说过,如果你有一个钉子,就会满大街找锤子!这两个现象在我们工作中每天都会上演。


手里有锤心中无锤不要见人就锤,工具是死的人是活的,不要被工具禁锢。by 知乎。1、使用工具要懂工具的魂,而不要做工具作恶的傀儡。2、用好工具,学会甄别工具、创造工具。不过在我看了,能创造工具的人真的很少,基本工具都是提炼、孵化出来的。


   关于道、术、器网上论述很多,可以自行搜索。这里把工具概念放大一下,把这个问题泛化。从不同层面看,语言层面、中间件层面、存储层面、开发框架层面、行业层面等难道不都是一种工具吗?PC技术、web技术、移动技术、ai技术不是都是一种实现“平行世界”的工具吗?新的思维方式、能力不是提升效率的工具?面临新技术(工具)我们怎么处理?我们不用太强调道、术、器,而强调应该具备哪些能力到底我们应该把时间花费到哪里?我引用三本书的内容,读者可以自己搜索学习。


l跟着高人“足迹”


   我们不一定能跟高人共事,但是跟着他的足迹应该是有可能的。如果能透过现象、发现规律、能感知到价值更好。


   李善友老师有本《第二曲线创新》很不错,里面提到“单一要素最大化”,聚焦第一曲线的一个要素,把它放大为第二曲线的全部。我们发现商业创新太难,但是我们可以跟着政策、高人或企业的发力点,布局自己的未来。新的商业创新背后一定会用到新的技术、工具、思路、能力。比如:移动互联网在10年左右随着智能手机普及,移动技术肯定会蓬勃发展,如果我们能10年左右学习智能手机相关技术、工具,肯定能个人利益最大化;入局这个产业生态,也会分得一杯羹。        当然例如共享单车、p2p、区块链,入局后失败惨重。 如何甄别这些呢?作为个人,对新的技术、模式一定要投入时间学习。作为创业者我们一定要对成熟生态做储备工作。例如:2年前抖音号获得粉丝的难度比现在容易多了,竞争压力小多了。    背后也可以用笨鸟先飞的思路来理解,如果平时可以训练写一手漂亮的文字或平时积极主动的分享,在这波知识付费势头下,肯定会有一番作为。


l该学什么,别贪多


   推荐我校友张萌美女《人生效率手册》中七个人物法。大致思路是写出自己想成为的或作为榜样的七个、层次不同的、职业目标人物;列出每个人在架构方面(当然其它也可以)的三项能力;按照聚合排序,选出三项能力或本领;然后死磕这些能力或本领。比如:我当初筛选技术方向时,明确未来几年,自己要向商业化广告、大数据、ai这几个方向学习。


   书中描述很详细,这里不累述。有明确目标了,不仅仅让自己有个灯塔,最重要的是你取舍拒绝将会很简单。时间管理将会很简单,抗诱惑能力也会加强。往往我们不是不知道做什么,而是不做什么决策不了

l 新时代的学习方法


古典老师有本书《跃迁:成为高手的技术》也很不错,里面提到联机学习的方法。移动互联网创造的了太多的信息、概念,人与人之前连接更多、更复杂。作为从业者,如何利用呢?联机学习可以称得上互联网时代全新的学习方式,值得拥有。


  我们不是不愿意学习,而是学习后,投入产出比较低,会丧失学习的动力。学会功利式学习,多读书、多总结、多分享,倒逼有价值的输入。


   注:这三本书真心推荐。


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
7月前
|
Linux 调度
单片机面向对象思维的架构:时间轮片法
单片机面向对象思维的架构:时间轮片法
96 0
|
存储 SQL 关系型数据库
【面试题精讲】MySQL逻辑架构
【面试题精讲】MySQL逻辑架构
|
4月前
|
设计模式 算法 PHP
深入理解PHP中的数组操作探索编程之美:从代码到架构的思维转变
【8月更文挑战第24天】在PHP编程中,数组是基础且强大的数据结构。本文将通过浅显易懂的方式,介绍如何在PHP中高效地操作数组,包括创建、遍历、排序和过滤等常见任务。无论你是初学者还是有经验的开发者,这篇文章都会带给你新的启示。 【8月更文挑战第24天】在编程的世界中,代码不仅仅是冰冷的字符排列,它承载着思想、解决问题的智慧和创新的灵魂。本文将通过个人的技术感悟,带领读者从编写单一功能的代码片段出发,逐步深入到整个软件架构的设计哲学,探索如何将代码块转化为高效、可维护和可扩展的系统。我们将一起见证,当代码与架构思维相结合时,如何引发技术实践的革命性飞跃。
|
4月前
|
设计模式 架构师 数据建模
架构师必备底层逻辑:设计与建模的技术深度探索
【8月更文挑战第13天】在软件开发的浩瀚星海中,架构师如同星辰指引,他们不仅规划着系统的蓝图,更在底层逻辑上精雕细琢,确保系统的稳健与高效。其中,“设计与建模”作为架构师的核心能力之一,是连接业务需求与技术实现的桥梁。本文将深入探讨架构师在设计与建模过程中的关键思维与实践方法,为工作学习中的技术同仁提供一份宝贵的干货分享。
69 3
|
4月前
|
开发工具 Android开发
Android项目架构设计问题之SDK内部减少每次回调时的冗余判断逻辑如何解决
Android项目架构设计问题之SDK内部减少每次回调时的冗余判断逻辑如何解决
47 0
|
4月前
|
Android开发 iOS开发
Android项目架构设计问题之将隐式跳转的逻辑进行抽象和封装如何解决
Android项目架构设计问题之将隐式跳转的逻辑进行抽象和封装如何解决
53 0
|
5月前
|
监控 安全 前端开发
交易所系统开发(源码正式版)/需求逻辑/玩法详情/规则架构
交易所源码开发是指基于特定的需求和要求,从头开始构建一个自定义的交易所平台的开发过程。这种开发可以包括以下几个关键方面:
|
5月前
|
运维 Java Docker
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
|
6月前
|
SQL 存储 缓存
第四章 逻辑架构(2)
第四章 逻辑架构
38 1
|
6月前
|
SQL 存储 缓存
第四章 逻辑架构(1)
第四章 逻辑架构
42 1

热门文章

最新文章