精华内容
下载资源
问答
  • 学习Spring的思考框架

    2019-10-14 19:00:00
    而之所以能问出来这些合理的问题,就是因为头脑中有自己的思考框架。比如要做一件事情,一个思考框架就是: 1,我们现在是什么样的? 2,我们要做成什么样(解决什么问题、有什么收益)? 3,怎么才能达成(解决...

     

    引子

    很早之前听同事说:“要开会了。我都知道领导要问什么,就那几板斧。”其实领导之所以为领导,人家问的问题确实很合情合理,甚至可以说一针见血。而之所以能问出来这些合理的问题,就是因为头脑中有自己的思考框架。比如要做一件事情,一个思考框架就是:

    1,我们现在是什么样的?

    2,我们要做成什么样(解决什么问题、有什么收益)?

    3,怎么才能达成(解决路径)?

     

    根据这个思考框架,开会的时候,给领导做汇报,一上来就说我做了什么什么。领导自然要问:“做这件事情有什么收益?” 如果一项任务指标特别好,领导就要问了:“那我们是怎么做到的呢?”

     

    这种框架式自上而下的思考习惯,对做任何事情都会有帮助。比如想学习Spring,就先问自己3个问题:

    1,出现Spring之前是什么样子?

    2,Spring的目标是什么?

    3,Spring是怎么做到的呢?

     

    出现Spring之前是什么样子

    出现Spring之前,MVC这种设计典范已经开始兴起。在显示层、模型层和控制层都有了一些工具的支持。比如显示层有JQuery+JSON,模型层有ibatis,控制层有Struts。开发人员的主要精力应该放到业务逻辑的开发。但是开发前需要做一件事情:将MVC需要的这些东西组装起来。每个人在新搭建一个工程时都需要进行组装。那有没有一个东西把开发人员需要的东西都弄好了,开发人员只需要将精力用户业务逻辑开发呢?

    Spring就是为了解决这个问题而生。

     

    Spring的目标是什么

    Spring就是要最大限度的简化开发工作,让开发人员集中精力于自己的业务逻辑,也是DDD领域驱动开发。

     

    Spring是怎么做到的呢

    核心问题解决

    1,解耦

    开发人员希望聚焦DDD的开发,首先要解决的事情是我修改一个业务代码,不希望显示层、模型层和控制层都要改。不希望改一个类,依赖它的类也需要改。Spring为了应对这个问题使用了控制反转的理念。将所有的依赖都由框架注入到一个上下文环境中(DI)。在这个环境中,Bean之间可以自由的使用。

    2,复用

    有了DI(依赖注入)的支持,开发人员可以具体聚焦DDD的开发了。一个优秀程序员的最大的美德是懒惰。一些逻辑,比如日志,鉴权,很多地方都需要用到。这个业务逻辑关系又不是很紧密,代码基本上就是拷贝一下。那怎么能将这些业务特点不强的逻辑从开发人员的工作中剔除掉呢?这就用到了AOP(面向切面)编程。

    以上Spring要解决的核心问题解耦和复用的解决方案就是Spring的核心:控制反转、依赖注入和AOP。

     

    核心功能实现

    为了将Spring的核心功能实现出来,就需要用到Robert Martin提出的SOLID原则。分别是单一职责、开放封闭、里氏替换、接口隔离和依赖倒置。

    控制反转、依赖注入和AOP,分别对应了三个spring的jar包:spring-beans、spring-context、spring-aop。每个包单一的负责一个核心功能的实现。这些都需要先做对象的实例化,这个功能由spring-core这个jar包来实现。

    在Spring-beans中,Spring使用工厂模式来管理程序中使用的对象Bean。每个Bean实例以BeanDefinition的形式被创建,通过java的反射机制将需要初始化的字段写入,最终保存在BeanDefinitionMap中。这整个过程由容器来实现,完成了控制反转。

    有了控制反转,开发者可以通过调用getBean获取到所需要的对象。spring-context提供文件列表的读入,将所有依赖的Bean放到一个Context中,就是常说的依赖注入。

    AOP的主要作用是不通过修改源代码的方式将功能代码织入来实现对方法的增强。实现的关键在于使用了代理模式。代理主要分为静态代理和动态代理。静态代理最简单的实现就是创建一个代理类,将对象new出来之后,在调用方法前后都加上代码。调用方调用代理类而不直接调用原始类。动态代理主要是JDK动态代理和Cglib动态代理,这里就不详细展开了。

     

    总结

    本文从技术上,只介绍了Spring框架部分的核心功能。大家可以按照这个思路继续将其他部分纳入体系。当然,本文用的思考框架也只是思考框架的一种,是偏产品化的一个视角。完全可以用偏技术化的视角比如:「是什么、为什么、怎么办」的思考框架,只要保持一个风格、梳理成体系就好。

    以上Spring相关的部分,用一张图总结如下

    640?wx_fmt=png

     

    温故知新

    Spring参数的自解析--还在自己转换?你out了!

    SpringBoot优雅退出

    SpringBoot整合web容器

    你看不懂的spring原理是因为不知道这几个概念

    专治不会看源码的毛病--spring源码解析AOP篇(2017版)

    关于作者

    作者是一个有美国硅谷、日本东京工作经验,十二年坚持一线写代码的程序媛。坚持原创文章。欢迎技术交流!

    640?wx_fmt=jpeg

    展开全文
  • 针对高可用的方法,思考框架如下: 指导原则 高可用 事前 副本技术 隔离技术 配额技术 探知技术 预案 监控和报警 降级 回滚 failXXX...

    本文来自kriszhang老师的分享。针对高可用的方法,思考框架如下:

    • 指导原则

    • 高可用

      事前

      • 副本技术

      • 隔离技术

      • 配额技术

      • 探知技术

      • 预案

      • 监控和报警

      • 降级

      • 回滚

      • failXXX系列

    • 高并发

      • 多线程

      • 扩容

      • 缓存

      • 异步

    1、指导原则

    书中所列举的,里有一些可能并不是原则,而是技巧。我理解的原则如下:

    高并发原则:

    1. 无状态设计:因为有状态可能涉及锁操作,锁又可能导致并发的串行化。

    2. 保持合理的粒度:无论拆分还是服务化,其实就是服务粒度控制,控制粒度为了分散请求提高并发,或为了从管理等角度提高可操性。

    3. 缓存、队列、并发等技巧在高并发设计上可供参考,但需依场景使用。

    高可用原则:

    1. 系统的任何发布必须具有可回滚能力。

    2. 系统任何外部依赖必须准确衡量是否可降级,是否可无损降级,并提供降级开关。

    3. 系统对外暴露的接口必须配置好限流,限流值必须尽量准确可靠。

    业务设计原则:

    1. 安全性:防抓取,防刷单、防表单重复提交,等等等等。

    2. at least 消费,应考虑是否采用幂等设计

    3. 业务流程动态化,业务规则动态化

    4. 系统owner负责制、人员备份制、值班制

    5. 系统文档化

    6. 后台操作可追溯

    以上原则只是大千世界中的一小部分,读者应当在工作学习中点滴积累。

     

    2、高可用

    我们先说高可用的本质诉求:高可用就是抵御不确定性,保证系统7*24小时健康服务。关于高可用,我们其实面对的问题就是对抗不确定性,这个不确定性来自四面八方。比如大地震,会导致整个机房中断,如何应对?比如负责核心系统的工程师离职了,如何应对?再比如下游接口挂了,如何应对?系统磁盘坏了,数据面临丢失风险,如何应对?

    我想关于上述问题的应对方式,大家在工作中或多或少都有所了解,而这个不确定性的处理过程,就是容灾,其不同的‘灾难’,对应不同的容灾级别。

    为了对抗这些不同级别的不确定性,就要付出不同级别的成本,因此可用性也应是有标准的。这标准就是大家常说的N个9。

    随着N的增加,成本也相应增加,那如何在达到业务需要的可用性的基础上,尽量节省成本?这也是一个值得思考的话题。除此之外,100%减去这N个9就说所谓的平均故障时间(MTBF),很多人只关心那些9,而忽略了故障处理时间,这是不该的:

    你的故障处理速度越快,系统的可用性才有可能越高。

    上面扯了一些可用性概念上的东西,下面来说一下技巧。开涛的书中没有对可用性技巧做出一个分类,我这里则尝试使用‘事情’来分个类。这里的‘事’就是故障,分为:事前(故障发生以前)、事发(故障发生到系统或人感知到故障)、事中(故障发生到故障处理这段时间)、事后(故障结束之后)。

    按照上述分类,不同的阶段应有着不同的技巧:

    事前:副本、隔离、配额、提前预案、探知
    事发:监控、报警
    事中:降级、回滚、应急预案,failXXX系列
    事后:复盘、思考、技改

     

    事前

    副本技术

    大自然是副本技术当之无愧的集大成者,无论是冰河时代,还是陨石撞击地球所带来的毁灭性打击,物种依然绵绵不绝的繁衍,这便是基因复制的作用。副本是对抗不确定性的有力武器,把副本技术引入计算机系统,也会带来高可用性的提升。

    无状态服务集群便是副本的一个应用,因为没有状态,便可水平伸缩,而这些无状态服务器之间需要一层代理来统一调度管理,这便有了反向代理。

    当代理通过心跳检测机制检测到有一台机器出现问题时,就将其下线,其他‘副本’机器继续提供服务;存储领域也是经常使用副本技术的,比如OB的三地三中心五副本技术等,mysql主备切换,rabbitMQ的镜像队列,磁盘的RAID技术,各种nosql中的分区副本,等等等等,数不胜数,几乎所有保证高可用的系统都有冗余副本存在。

     

    隔离技术

    书上提到了很多种隔离:线程隔离、进程隔离、集群隔离、机房隔离、读写隔离、动静隔离、爬虫隔离、热点隔离、硬件资源隔离。

    在我看来,这些隔离其实就是一种,即资源隔离,无论线程、进程、硬件、机房、集群都是一种资源;动态资源和静态资源也不过是资源的一种分类;热点隔离也即是热点资源和非热点资源的隔离;读写隔离不过仅仅是资源的使用方式而已,相同的两份资源,一份用来写,一份用来读。

    因此,隔离的本质,其实就是对资源的独立保护。因为每个资源都得到了独立的保护,其中一个资源出了问题,不会影响到其他资源,这就提高了整体服务的可用性。人类使用隔离术也由来已久了,从农业养殖,到股票投资,甚至关犯人的监狱,都能找到隔离术的影子。

     

    配额技术

    配额技术通过限制资源供给来保护系统,从而提高整体可用性。限流是配额技术的一种,它通过调节入口流量水位上线,来避免供给不足所导致的服务宕机。

    限流分为集群限流和单机限流,集群限流需要分布式基础设施配合,单机限流则不需要。大部分业务场景使用单机限流足以,特殊场景(类秒杀等)下的限流则需限制整个集群。除此之外,限流这里我们还需要考虑几点:

    如何设置合理的限流值?限流值的设定是需要经过全链路压测、妥善评估CPU容量、磁盘、内存、IO等指标与流量之间的变化关系(不一定线性关系)、结合业务预估和运维经验后,才能确定。

    对于被限流的流量如何处理?有几种处理方式,其一直接丢弃,用温和的文案提醒用户;其二,静默,俗称的无损降级,用缓存内容刷新页面;其三,蓄洪,异步回血,这一般用于事务型场景。

    会不会导致误杀?单机限流会导致误杀,尤其当负载不均衡的情况下,很容易出现误杀;单机限流值设定过小也容易出现误杀的情况。

     

    探知技术

    其只用于探知系统当前可用性能力,无法切实提高系统可用性,做不好甚至还会降低系统可用性。压测和演练和最常见的探知技术 。压测分为全链路压测和单链路压测,全链路压测用于像双十一大促活动等,需要各上下游系统整体配合,单链路压测一般验证功能或做简单的单机压测提取性能指标。

    全链路压测的一般过程是:压测目标设定和评估,压测改造,压测脚本编写部署,压测数据准备,小流量链路验证,通知上下游系统owner,压测预热,压测,压测结果评估报告,性能优化。以上过程反复迭代,直到达到压测目标为止;

    演练一般按规模划分:比如城市级别的容灾演练,机房级别的容灾演练,集群规模的容灾演练(DB集群,缓存集群,应用集群等),单机级别的故障注入,预案演练等。演练的作用无需过多强调,但演练一般发生在凌晨,也需要各系统owner配合排错,着实累人,一般都是轮班去搞。

     

    预案

    预案一般分为提前预案(事前)和应急预案(事中)。提前预案提前执行,比如将系统临时从高峰模式切换成节能模式;应急预案关键时刻才执行,主要用于止血,比如一键容灾切换等。预案技术一般要配合开关使用,推预案一般也就是推开关了。除此之外,预案也可和限流、回滚、降级等相结合,并可以作为一个定期演练项目。

     

    事发

    事发是指当故障发生了到系统或人感知到故障准备处理的这段时间,核心诉求即是如何快速、准确的识别故障。

     

    监控和报警

    一般出现故障的时候,老板大多会有三问:为什么才发现?为什么才解决?影响有多大?即使故障影响面较大,如果能迅速止血,在做复盘的时候多少能挽回一些面子,相反如果处理不及时,即使小小的故障,都可能让你丢了饭碗。越早识别故障,就能越早解决问题,而这眼睛便是监控和报警了。监控报警耳熟能详,这里不多赘述。

     

    事中

    事中是指当故障发生时,为了保证系统可用性,我们可以或必须做的事情。分为降级、回滚、应急预案(见上文,这里不多数了),faillXXX系列。

     

    降级

    降级的内涵丰富,我们只从链路角度去思考。降级的本质是弃车保帅,通过临时舍弃部分功能,保证系统整体可用性。降级虽然从整体上看系统仍然可用,但由于取舍的关系,那么可知所有的降级一定是有损的。不可能有真正的无损降级,而常说的无损降级指的是用户体验无损。

    降级一定发生在层与层之间(上下游),要么a层临时性不调用b层,这叫做熔断,要么a层临时调用c层(c层合理性一定<b层),这叫备用链路。

    无论是哪一种方式,都会面临一个问题:如何确定什么时候降级,什么时候恢复?一般有两种方式,

    其一是人工确认,通过监控报警等反馈机制,人工识别故障,推送降级,待故障恢复后在手动回滚;

    其二是自适应识别,最常用的指标有超时时间、错误次数、限值流等等,当达到阈值时自动执行降级,恢复时自动回滚。

    这两种方式无需对比,它们都是经常采用的高可用技巧。

    除此之外,我们还要注意降级和强弱依赖的关系。强弱依赖表示的是链路上下游之间的依赖关系,是’是否可降级‘的一种专业表述。

    我们再来看书中的一些降级的例子:

    ①读写降级,实际上是存储层和应用层之间的降级,采用备用链路切换方式,损失了一致性;

    ②功能降级,将部分功能关闭,实际上是应用层和功能模块层之间的降级,采用熔断方式,损失了部分功能。

    ③爬虫降级,实际上是搜索引擎爬虫和应用系统之间的降级,采用备用链路切换方式,将爬虫引导到静态页面,损失是引擎索引的建立和页面收录。

     

    回滚

    当执行某种变更出现故障时,最为稳妥和有效的办法就是回滚。虽然回滚行之有效,但并不简单,因为回滚有一个大前提:变更必须具有可回滚性。

    而让某一种变更具有可回滚的特性,是要耗费很大力气的。索性的是,大部分基础服务已经帮我们封装好了这一特性,比如DB的事务回滚(DB事务机制),代码库回滚(GIT的文件版本控制),发布回滚(发布系统支持)等等。

    我们在日常变更操作的时候,必须要确定你的操作是否可回滚,并尽力保证所有变更均可回滚。如果不能回滚,是否可以进行热更新(比如发布应用到app store)或最终一致性补偿等额外手段保证系统高可用。

    failXXX系列

    当出现下游调用失败时,我们一般有几种处理方式:

    1. failretry,即失败重试,需要配合退避时间,否则马上重试不一定会有效果。

    2. failover,即所谓的故障转移。比如调用下游a接口失败,那么RPC的负载均衡器将会调用a接口提供方的其他机器进行重试;在比如数据库x挂了,应用自适应容灾将对x库的调用切换到y库调用,此y库即可以是faillover库(流水型业务),也可以备库(状态型业务)。

    3. failsafe,即静默,一般下游链路是弱依赖的时候,可以采用failsafe,即可和failover相结合,比如failover了3次还是失败,那么执行failsafe。

    4. failfast,立即报错,failfast主要让工程师快速的感知问题所在,并及时进行人工干预。

    5. failback,延迟补偿(回血),一般可以采用消息队列或定时扫描等。

    上面的1,2,4是属于重试策略,即书中《超时与重试》章节所讲到的重试。重试有个问题:退避间隔是多少?重试几次?一般在下游临时抖动的情况下,很短时间内就可以恢复;但当下游完全不可用,那么很有可能重试多少次都不会成功,反而会对下游造成了更大的压力,那这种情况就应当做用熔断了。

    所以正确设定重试次数、选择退避时间等都是需要仔细思考的。我们在来说一下超时,超时只是一种预防机制,不是故障应对策略,其主要为了防止请求堆积——资源都用于等待下游请求返回了。堆积的后果自不用多说,重要的是如何选择正确的超时时间?书上只说了链路每个部分超时时间怎么配置,却不知道应配置多少,这是不够全面的。

     

    事后

    复盘、思考、技改。不多赘述。

     

    2、高并发

    如果仅是追求高可用性,这其实并不难做,试想如果一年只有一个人访问你的系统,只要这一个人访问成功,那你系统的‘’可用性‘就是100%了。

    可现实是,随着业务的发展,请求量会越来越高,进而各种系统资源得以激活,那潜在风险也会慢慢的暴露出来。

    因此,做系统的难点之一便是:如何在高并发的条件下,保证系统的高可用。上文已经说了一些保证高可用的技巧,这节将结合开涛的书,说说高并发。

    上图是我们生活中常见的一个场景——排队购物。收银员就是我们的服务,每一个在队列中的顾客都是一个请求。我们的本质诉求是让尽可能多的人都在合理的等待时间内完成消费。

    如何做到这一点呢?其一是提高收银员的处理速度,他们处理的越快,单位时间内就能服务更多的顾客;其二是增加人手,一名收银员处理不过来,我们就雇十名收银员,十名不够我们就雇佣一百名(如果不计成本);其三是减少访问人数,也即分流过滤,将一些人提前过滤掉,或做活动预热(比如双十一预热),在高峰之前先满足一部分人的需求。因此,想要高并发无外乎从以下几个方面入手:

    提高处理速度:缓存、异步
    增加处理人手:多线程(多进程)、扩容
    减少访问人数:预处理(本文不涉及)

    提高处理速度

    缓存

    缓存之所以能够提高处理速度,是因为不同设备的访问速度存在差异。缓存的话题可以扯几本书不带重样的。从CPU可以一直扯到客户端缓存,即从最底层一直到扯到最特近用户的一层,每一层都可能或可以有缓存的存在。我们这里不扯这么多,只说简单服务端缓存。现在从几个不同角度来看一下缓存:

    ①从效果角度。命中率越高越好吗?10万个店铺数据,缓存了1000个,命中率稳定100%,那是不是说,有99000个店铺都是长尾店铺?缓存效果评估不能单看命中率。

    ②从回收策略。如果把缓存当做数据库一样的存储设备去用,那就没有回收的说法了(除非重启或者宕机,否则数据依然有效);如果只存储热数据,那就有回收和替换的问题。回收有两种方式,一种是空间配额,另一种是时间配额。替换也有几种方式,LRU,FIFO,LFU。

    ③从缓存使用模式角度:用户直接操作缓存和db;用户直接操作缓存,缓存帮助我们读写DbB;

    ④从缓存分级角度。java堆内缓存、java堆外缓存、磁盘缓存、分布式缓存,多级缓存。

    ⑤从缓存使用角度。null穿透问题、惊群问题、缓存热点问题、缓存一致性问题、读写扩散问题……

    ⑥更新方式。读更新、写更新、异步更新。

    如果缓存集群涉及到异地多集群部署,再结合大数据量高并发业务场景,还会遇到很多更加复杂的问题,这里就不一一列举了。

     

    异步

    异步这里有几点内涵,

    其一是将多个同步调用变成异步并发调用,这样就将总响应时间由原来的t1+t2+t3+…..+tn变成了max(t1,t2,t3….,tn),这也叫异步编排;

    其二是在操作系统层面,使用asyc io以提高io处理性能;

    其三是将请求’转储‘,稍后异步进行处理,一般使用队列中间件。其中的异步编排,可以使用CompletableFuture;异步IO一般框架都做了封装;而队列中间件则是最为常用的技术之一,也是我们重点关注的对象。

    业务允许延迟处理,是使用队列中间件的大前提,即非实时系统或准实时系统更适合使用。主要作用有:异步处理(增加吞吐),削峰蓄洪(保障稳定性),数据同步(最终一致性组件),系统解耦(下游无需感知订阅方)。

    • 缓冲队列:一般使用环形缓冲队列,控制缓冲区大小。

    • 任务队列:一般用于任务调度系统,比如线程池等,disrupter

    • 消息队列:一般意义上的消息中间件,不同业务场景需要的中间件能力不同,有的需要高吞吐,有的需要支持事务,有的需要支持多客户端,有的需要支持特定协议等等,妄图开发一个大而全的消息队列,个人觉得不如提供多种队列按需选型,之后在统一提供一个通信中台,全面整合消息能力。

    • 请求队列:就是处理请求的队列,有点像流程引擎,可以做一些前置后置的入队出队处理,比如限流、过滤等等

    • 数据总线队列:比如canal,datax等数据(异构或同构)同步用的。

    • 优先级队列:一般大根堆实现

    • 副本队列:如果队列支持回放,副本队列有些冗余。

    • 镜像队列:一般用于做队列系统的高可用切换的。

      有时候也跨集群跨机房做复制,提供更多消费者消费,增加投递能力。

    队列的消费端有pull模式或者push模式的选取。pull模式可以控制进度,push模式则实时性更高一些;pull能支持单队列上的有序,push很难支持。除了消费模式,队列还有一系列其他问题请参考其他书籍,这里不多说明了。

    这里在补充一点关于异步的说明。同步转异步,可以提高吞吐量;异步转同步,可以增加可靠性。

    增加处理人手

     

    多线程

    多线程(多进程)技术是‘增加处理人手’技术中最容易想到的,一般我们也广泛采用。无论是web服务容器、网关、RPC服务端、消息队列消费和发送端等等都有使用多线程技术。其优点也无需过多说明。

    这里我们只说一件重要的事情,即线程数的设置问题,如果线程数过高则可能会吃光系统资源,如果过低又无法发挥多线程优势。

    一般设置的时候,会参考平均处理时长、并发峰值、平均并发量、阻塞率、最长可容忍响应时间、CPU核心数等等,然后做一定的运算,计算出线程数、core和max,以及阻塞队列大小。

    具体算法可以自行谷歌。

     

    扩容

    在无状态服务下,扩容可能是迄今为止效果最明显的增加并发量的技巧之一。

    有临时性并发问题时,可以直接提扩容工单,立竿见影。但扩容的最大问题就是成本了,想想动辄几万的实体机,如果只是为了支撑一个小时的大促,而平常利用率几乎为0,那确实是浪费。

    因此便有了弹性云,当需要扩容时,借别人机器(阿里云)用完再还回去;以及离线在线混部,充分利用资源。

    从扩容方式角度讲,分为垂直扩容(scale up)和水平扩容(scale out)。

    垂直扩容就是增加单机处理能力,怼硬件,但硬件能力毕竟还是有限;水平扩容说白了就是增加机器数量,怼机器,但随着机器数量的增加,单应用并发能力并不一定与其呈现线性关系, 此时就可能需要进行应用服务化拆分了。

    从数据角度讲,扩容可以分为无状态扩容和有状态扩容。

    无状态扩容一般就是指我们的应用服务器扩容;有状态扩容一般是指数据存储扩容,要么将一份数据拆分成不同的多份,即sharding,要么就整体复制n份,即副本。

    sharding遇到的问题就是分片的可靠性,一般做转移、rehash、分片副本;副本遇到的问题是一致性性,一般做一致性算法,如paxos,raft等。

     


    =>更多文章请参考《中国互联网业务研发体系架构指南》https://blog.csdn.net/Ture010Love/article/details/104381157

    =>更多行业架构案例及行业标准资料请关注微信公众号:

    公众号:关注更多实时动态
    更多内容关注公众号:软件真理与光

     

    展开全文
  • 读书笔记-工作方式 将时间的利用率提高,真正的效率,来自少做乃至不做无价值的事。 文章目录读书笔记-工作方式前言一、以终为始二、...在工作中更多的注重去思考,形成自己的工作原则和思考框架。 对自己职业生涯也进

    读书笔记-工作方式

    将时间的利用率提高,真正的效率,来自少做乃至不做无价值的事。



    前言

    在极客时间上学习了郑晔老师的《10x程序员工作法》 课程,感觉受益匪浅,在学习过程中,将老师的知识用脑图的形式记录下来,在这里做个分享,不足之处欢迎大家指出。


    提示:以下是本篇文章正文内容

    一、以终为始

    在这里插入图片描述

    二、任务分解

    在这里插入图片描述

    三、沟通反馈

    在这里插入图片描述

    四、自动化

    在这里插入图片描述

    总结

    在工作中更多的注重去思考,形成自己的工作原则和思考框架。

    对自己职业生涯也进行一些思考以及行动。
    在这里插入图片描述

    在接下来的工作中,更去注重实践。

    1. 拿到需求,先看验收标准,看用户需要的产品是什么,多问几个为什么,在大脑中进行沙盘演练,推测测试-预上线-上线过程中可能存在的问题。
    2. 确认需求后,进行任务分解,坚持任务拆分,变成小任务,做好需求把控的同时,也进行对应的单元测试编写。利用脑图的形式,将业务功能的实现步骤进行思考,少走弯路。
    3. 进行多沟通,能够面对面尽量面对面沟通,定期复盘减少阻塞,遇到问题提前反馈,Fast Fail原则。

    献上我的思维导图笔记
    在这里插入图片描述

    展开全文
  • 而之所以能问出来这些合理的问题,就是因为头脑中有自己的思考框架。比如要做一件事情,一个思考框架就是:1,我们现在是什么样的?2,我们要做成什么样(解决什么问题、有什么收益)?3,怎么才能达成(解决路径)?...

    引子

    很早之前听同事说:“要开会了。我都知道领导要问什么,就那几板斧。”其实领导之所以为领导,人家问的问题确实很合情合理,甚至可以说一针见血。而之所以能问出来这些合理的问题,就是因为头脑中有自己的思考框架。比如要做一件事情,一个思考框架就是:

    1,我们现在是什么样的?

    2,我们要做成什么样(解决什么问题、有什么收益)?

    3,怎么才能达成(解决路径)?

    根据这个思考框架,开会的时候,给领导做汇报,一上来就说我做了什么什么。领导自然要问:“做这件事情有什么收益?” 如果一项任务指标特别好,领导就要问了:“那我们是怎么做到的呢?”这种框架式自上而下的思考习惯,对做任何事情都会有帮助。比如想学习Spring,就先问自己3个问题:

    1,出现Spring之前是什么样子?

    2,Spring的目标是什么?

    3,Spring是怎么做到的呢?

    出现Spring之前是什么样子

    出现Spring之前,MVC这种设计典范已经开始兴起。在显示层、模型层和控制层都有了一些工具的支持。比如显示层有JQuery+JSON,模型层有ibatis,控制层有Struts。开发人员的主要精力应该放到业务逻辑的开发。但是开发前需要做一件事情:将MVC需要的这些东西组装起来。每个人在新搭建一个工程时都需要进行组装。那有没有一个东西把开发人员需要的东西都弄好了,开发人员只需要将精力用户业务逻辑开发呢?Spring就是为了解决这个问题而生。

    Spring的目标是什么

    Spring就是要最大限度的简化开发工作,让开发人员集中精力于自己的业务逻辑,也是DDD领域驱动开发。

    Spring是怎么做到的呢

    核心问题解决

    1,解耦

    开发人员希望聚焦DDD的开发,首先要解决的事情是我修改一个业务代码,不希望显示层、模型层和控制层都要改。不希望改一个类,依赖它的类也需要改。Spring为了应对这个问题使用了控制反转的理念。将所有的依赖都由框架注入到一个上下文环境中(DI)。在这个环境中,Bean之间可以自由的使用。

    2,复用

    有了DI(依赖注入)的支持,开发人员可以具体聚焦DDD的开发了。一个优秀程序员的最大的美德是懒惰。一些逻辑,比如日志,鉴权,很多地方都需要用到。这个业务逻辑关系又不是很紧密,代码基本上就是拷贝一下。那怎么能将这些业务特点不强的逻辑从开发人员的工作中剔除掉呢?这就用到了AOP(面向切面)编程。以上Spring要解决的核心问题解耦和复用的解决方案就是Spring的核心:控制反转、依赖注入和AOP。

    核心功能实现

    为了将Spring的核心功能实现出来,就需要用到Robert Martin提出的SOLID原则。分别是单一职责、开放封闭、里氏替换、接口隔离和依赖倒置。控制反转、依赖注入和AOP,分别对应了三个spring的jar包:spring-beans、spring-context、spring-aop。每个包单一的负责一个核心功能的实现。这些都需要先做对象的实例化,这个功能由spring-core这个jar包来实现。在Spring-beans中,Spring使用工厂模式来管理程序中使用的对象Bean。每个Bean实例以BeanDefinition的形式被创建,通过java的反射机制将需要初始化的字段写入,最终保存在BeanDefinitionMap中。这整个过程由容器来实现,完成了控制反转。有了控制反转,开发者可以通过调用getBean获取到所需要的对象。spring-context提供文件列表的读入,将所有依赖的Bean放到一个Context中,就是常说的依赖注入。AOP的主要作用是不通过修改源代码的方式将功能代码织入来实现对方法的增强。实现的关键在于使用了代理模式。代理主要分为静态代理和动态代理。静态代理最简单的实现就是创建一个代理类,将对象new出来之后,在调用方法前后都加上代码。调用方调用代理类而不直接调用原始类。动态代理主要是JDK动态代理和Cglib动态代理,这里就不详细展开了。

    总结

    本文从技术上,只介绍了Spring框架部分的核心功能。大家可以按照这个思路继续将其他部分纳入体系。当然,本文用的思考框架也只是思考框架的一种,是偏产品化的一个视角。完全可以用偏技术化的视角比如:「是什么、为什么、怎么办」的思考框架,只要保持一个风格、梳理成体系就好。以上Spring相关的部分,用一张图总结如下

    b0487cc5307e490089962294970081bb.png

    温故知新

    Spring参数的自解析--还在自己转换?你out了!

    SpringBoot优雅退出

    SpringBoot整合web容器

    你看不懂的spring原理是因为不知道这几个概念

    专治不会看源码的毛病--spring源码解析AOP篇(2017版)

    展开全文
  • 算法优化的思考框架

    2019-03-08 19:30:04
    芯片和指令集层面 特定芯片的SDK,例如,PowerSDK neon指令集(32 bit/64 bit) 操作系统层面 CPU亲和操作(set_affinity) 线程调度方案设计,例如,锁的作用域的精准设置 第三方依赖库层面 ......
  • 前端项目的思考框架

    2017-08-08 00:08:00
    思考框架 这里的思考内容是要给页面交互应该考虑到的一些内容。 UI切图 UI组件 用户交互 API服务端交互 Native APP 调用 数据统计所需要的埋点 依赖的兄弟团队 兼容问题 其他必要说明 ...
  • SaaS是个B端产品中非常受关注的领域。2020年是B端产品发展的重要一年。特别检索了一篇英文资料,提供一份学习和提升SaaS产品能力的框架清单。按图索骥,提升我们的SaaS产品能力。构...
  • 这是一张用FreeMind画的框架,具体的分析将逐渐展开。
  • 拆解问题思考框架

    2021-01-28 14:44:04
  • 思考軟件,創新設計:A段架構師的思考技術》 ==> 請看目錄     3. 欢迎访问 => 高老师的ADT技术论坛 EE EE   By 高焕堂 -- MISOO(大数据.大思考)联盟.台北中心和东京(日本...
  • 思考框架

    2019-09-23 10:12:19
    四个思考原则 产品交给一个功能的时候,问题示例: 这个功能会给用户带来什么价值 什么样的用户,什么场景下,会怎么使用这个特性 是否还有其他手段达成目标 如何衡量功能的有效性和收益 问题需要遵循的四个原则...
  • Java框架研发思考

    2017-07-11 20:16:57
    Java架研发思考
  • web框架思考

    2016-03-28 02:49:00
    以前一直不明白web框架是怎样实现路由、orm、接受请求的。今天看了下廖雪峰的python 实现web框架博客才明白。 简单总结并记录: http请求-》wsgi-》处理请求-》返回html或其他数据 wsgi:可以理解成该接口根据...
  • 思考js框架模型

    2012-09-27 11:29:29
    但是又没有想过,框架和库到底什么关系?     库是什么?  -------- 一堆的代码 经验与代码的积累 业务需求的预处理 框架是什么?  -------- 一堆的规则 框架包含库 库只有...
  • Thrift框架 配图一张,主程序的流程图: 底层的(I/O)模块:负责实际的数据传输,比如Socket、文件、压缩数据流等的传输。 TTransport(负则传输的模块,就是底层I/O的实现):每一种传输方式都对应一个该模块,比如...
  • 关于前端框架思考

    2021-02-21 11:53:57
    关于前端框架思考导读重点 导读 一、百花齐放的前端框架 以前,最火的前端框架是 jQuery,后来又出现了 Dojo、Ember、Backbone、RequireJS、Angular、Vue、React… 一大堆框架。 目前,大家能在市面上看到的前端...
  • UI设计框架思考

    2020-03-05 19:52:15
    可扩展性——无论产品功能是简单还是复杂,布局框架能够随着产品需求的变化进行布局结构的延展和扩充 可预测性——选择可预测和可识别的布局,并连接到体验的每一个环境中且在适当的地方引导用户 魔方视觉的设计原则...
  • Java框架思考

    2019-10-07 04:04:22
    目前的JAVA 企业级开发框架,我们常用的大致包括IOC AOP MVC ORM框架 1、 IOC spring是一个非常棒的ico容器,其思想非常简单,用一个集合对象如MAP 来缓存对象(对象都是单例的),这也就是spring 所说容器内...
  • Java开发框架思考

    2016-02-25 14:24:59
     今年我一直在思考web开发里的前后端分离的问题,到了现在也颇有点心得了,随着这个问题的深入,再加以现在公司很多web项目的控制层的技术框架由struts2迁移到springMVC,我突然有了一个新的疑问无法得到正确的解释...
  • 数据分析框架思考

    2019-06-08 21:23:22
    以接到的一份分析需求为例,简单写下自己平时分析的一个思考的逻辑,并不一定是最正确科学的,在以后会被自己推翻,但是是现在最习惯的一种流。 一、需求交流 为了避免需求不清晰导致大量的重复工作、无效工作,在一...
  • 关于适配框架思考

    2020-12-01 12:53:54
    但是对于静态扫描框架一筹莫展,不知能否给一些提示,如何适配php的框架,比如laravel、symfony、yii等,以及可能会取得什么样的效果。或者采用php运行时检测hook的那种方式能取得比较好的...
  • 插件开发框架其实和目前开源界流行的MVC框架之类的相同,都决定了基于这个框架的开发方式,如基于MVC框架,就会按照MVC思想来进行开发,而插件开发框架呢,也是同样如此,就要求基于插件的方式来进行开发,不过插件...
  • 关于框架的一些思考

    2019-10-03 00:08:44
    如果你的团队很小并且在软件开发领域也没什么经验,那么放下包袱使用开源框架吧(OSS Framework),但是如果你有一个很大而且有丰富经验的团队,那么最好还是开发自己的框架。什么是框架,并没有明确的解释,但是似乎...
  • Mybatis框架思考与总结为什么很多公司都不用Mybatis自带二级缓存如何关闭一级缓存解析全局配置文件创建了什么对象四大对象什么时候创建的同类工具选型参考,如何在Mybatis和其他框架进行选择 为什么很多公司都不用...
  • 框架应用的思考

    2014-11-05 10:31:56
    目前很多产品是java开发的,而在java世界中有着各样的框架,各自都有着强大的功能和特点,但纠其本质都是为需求和业务而生,而许多需求大同小异,且有共同之处,只要掌握主要关注的内容再了解不同框架的自身特点就不...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,010
精华内容 3,604
关键字:

思考框架