精华内容
下载资源
问答
  • 架构思维
    千次阅读
    2020-11-25 17:21:39

    导读:架构师是一个既能掌控整体又能洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。看似完美的“人格模型”背后,是艰辛的探索。本文对多年的架构经验进行系统性地总结,帮助更多架构师在进阶这条路上走得更“顺畅”,姿态更“优雅”。

    架构师职责

    架构师不是一个人,他需要建立高效卓越的体系,带领团队去攻城略地,在规定的时间内完成项目。

    架构师需要能够识别定义并确认需求,能够进行系统分解形成整体架构,能够正确地技术选型,能够制定技术规格说明并有效推动实施落地。

    按 TOGAF 的定义,架构师的职责是了解并关注实际上关系重大但未变得过载的一些关键细节和界面,架构师的角色有:理解并解析需求,创建有用的模型,确认、细化并扩展模型,管理架构。

    从业界来看对于架构师的理解可以大概区分为:

    • 企业架构师:专注于企业总体 IT 架构的设计。
    • IT 架构师-软件产品架构师:专注于软件产品的研发。
    • IT 架构师-应用架构师:专注于结合企业需求,定制化 IT 解决方案;大部分需要交付的工作包括总体架构、应用架构、数据架构,甚至部署架构。
    • IT 架构师-技术架构师:专注于基础设施,某种软硬件体系,甚至云平台,提交:产品建议、产品选型、部署架构、网络方案,甚至数据中心建设方案等。

    架构思维

    自顶向下构建架构

    要点主要如下:

    1.首先定义问题,而定义问题中最重要的是定义客户的问题。定义问题,特别是识别出关键问题,关键问题是对客户有体感,能够解决客户痛点,通过一定的数据化来衡量识别出来,关键问题要优先给出解决方案。

    2.问题定义务必加入时间维度,把手段/方案和问题定义区分开来。

    3.问题定义中,需要对问题进行升层思考后再进行升维思考,从而真正抓到问题的本质,理清和挖掘清楚需求;要善用第一性原理思维进行分析思考问题(通过第一原理,我把事情升华到最根本的真理(本质),然后从最核心处开始推理……)。 第一性原理请看《优秀架构师必须掌握方法论(第一性原理)》

    4.问题解决原则:先解决客户的问题(使命),然后才能解决自己的问题(愿景);务必记住不是强调我们怎么样,而是我们能为客户具体解决什么问题,然后才是我们变成什么,从而怎么样去更好得服务客户。

     

    5.善用多种方法对客户问题进行分析,转换成我们产品或者平台需要提供的能力,比如仓储系统 WMS 可以提供哪些商业能力。

    6.对我们的现有的流程和能力模型进行梳理,找到需要提升的地方,升层思考和升维思考真正明确提升部分。

    7.定义指标,并能够对指标进行拆解,然后进行数学建模。

    8.将抽象出来的能力诉求转换成技术挑战,此步对于技术人员来说相当于找到了靶子,可以进行方案的设计了,需要结合自底向上的架构推导方式。

    9.创新可以是业务创新,也可以是产品创新,也可以是技术创新,也可以是运营创新,升层思考、升维思考,使用第一性原理思维、生物学(进化论--进化=变异+选择+隔离、熵增定律、分形和涌现)思维等哲科思维可以帮助我们在业务,产品,技术上发现不同的创新可能。可以说哲科思维是架构师的灵魂思维。

     

    image

    自底向上推导应用架构

    先根据业务流程,分解出系统时序图,根据时序图开始对模块进行归纳,从而得到粒度更大的模块,模块的组合/聚合构建整个系统架构。

     

    基本上应用逻辑架构的推导有4个子路径,他们分别是:

    1. 业务概念架构:业务概念架构来自于业务概念模型和业务流程;
    2. 系统模型:来自于业务概念模型;
    3. 系统流程:来自业务流程;
    4. 非功能性的系统支撑:来自对性能、稳定性、成本的需要。

    效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素,所以从逻辑架构到物理架构,一定需要先对效率、稳定性和性能做出明确的量化要求。

    自底向上重度依赖于演绎和归纳。

    如果是产品方案已经明确,程序员需要理解这个业务需求,并根据产品方案推导出架构,此时一般使用自底向上的方法,而领域建模就是这种自底向上的分析方法。

    对于自底向上的分析方法,如果提炼一下关键词,会得到如下两个关键词:

    1.演绎:演绎就是逻辑推导,越是底层的,越需要演绎:

    • 从用例到业务模型就属于演绎;
    • 从业务模型到系统模型也属于演绎;
    • 根据目前的问题,推导出要实施某种稳定性措施,这是也是演绎。

    2.归纳:这里的归纳是根据事物的某个维度来进行归类,越是高层的,越需要归纳:

    • 问题空间模块划分属于归纳;
    • 逻辑架构中有部分也属于归纳;
    • 根据一堆稳定性问题,归纳出,事前,事中,事后都需要做对应的操作,是就是根据时间维度来进行归纳。

     

    image

    领域驱动设计架构

    大部分传统架构都是基于领域模型分析架构,典型的领域实现模型设计可以参考DDD(领域驱动设计),详细可以参考《实现领域驱动设计》这本书,另外《UML和模式应用》在领域建模实操方面比较好,前者偏理论了解,后者便于落地实践。

    领域划分设计步骤:

    1.对用户需求场景分析,识别出业务全维度 Use Case;

    2.分析模型鲁棒图,识别出业务场景中所有的实体对象。鲁棒图 —— 是需求设计过程中使用的一种方法(鲁棒性分析),通过鲁棒分析法可以让设计人员更清晰,更全面地了解需求。它通常使用在需求分析后及需求设计前做软件架构分析之用,它主要注重于功能需求的设计分析工作。需求规格说明书为其输入信息,设计模型为其输出信息。它是从功能需求向设计方案过渡的第一步,重点是识别组成软件系统的高级职责模块、规划模块之间的关系。鲁棒图包含三种图形:边界、控制、实体,三个图形如下:

     

    image

    3、领域划分,将所有识别出的实体对象进行分类;

    4、评估域划分合理性,并进行优化。

    基于数据驱动设计架构

    随着 IoT、大数据和人工智能的发展,以领域驱动的方式进行架构往往满足不了需求或者达不到预期的效果,在大数据时代,在大数据应用场景,我们需要转变思维,从领域分析升维到基于大数据统计分析结果来进行业务架构、应用架构、数据架构和技术架构。这里需要架构师具备数理统计分析的基础和 BI 的能力,以数据思维来架构系统,典型的系统像阿里的数据分析平台采云间和菜鸟的数据分析平台 FBI。

    上述四种思维,往往在架构设计中是融合使用的,需要根据业务或者系统的需求来选择侧重思维方式。

    有了架构思维的指导,具体有没有通用/标准化的架构框架以更好的执行架构设计?答案是肯定的,请关注我,后续将为您揭晓。

    更多相关内容
  • 本文来自于infoq,文章主要介绍了抽象思维,分层思维,分治思维,演化思维。如果要问软件研发/系统架构中最重要的能力是什么,我会毫不犹豫回答是抽象能力。抽象(abstraction)这个词大家经常听到,但是真正理解和能...
  • 人人都要学的架构思维_技术领导力
  • 很详细的JAVA入门到架构师的完整学习路线,包含各种后台技术、前端技术、运维技术、架构知识等
  • 架构思维导图

    千次阅读 2020-11-01 23:12:32
    微服务架构根据目前产品存在的问题,针对快速开发、海量用户、大量数据、低延迟等互联网应用的实际需要,通过对业务架构、系统架构、基础架构、技术架构进行设计,彻底解决系统解耦、性能低下等问题,而且支持云计算...

    项目微服务架构图

    微服务架构根据目前产品存在的问题,针对快速开发、海量用户、大量数据、低延迟等互联网应用的实际需要,通过对业务架构、系统架构、基础架构、技术架构进行设计,彻底解决系统解耦、性能低下等问题,而且支持云计算部署,可以满足高并发、高可用、高稳定。

    项目计划

    项目计划是根据对未来的项目决策,项目执行机构选择制定包括项目目标、工程标准、项目预算、实施程序及实施方案等的活动。制定项目计划思维导图旨在消除或减少不确定性; 改善经营效率; 对项目目标有更好的理解。项目计划思维导图用于协调所有项目计划编制文件、指导项目执行和控制的文件。

    项目产品诞生过程

    项目产品诞生到运营过程的思维导图,能够清楚的了解到项目产品从设计到运营的过程。产品、项目研发基本流程概述:总体五个阶段、第一阶段需求采集、分析评估;第二阶段产品内部评审;第三阶段产品设计研发;第四阶段产品研发;第五个阶段产品验收。

    项目管理九大体系

    项目管理思维导图包括项目采购管理、项目成本核算、时间管理等关于项目管理的九大体系。项目管理十大领域:进度、成本、质量、范围等4个核心领域,风险、沟通、采购、人力资源、干系人等5个辅助领域,1个整体领域。项目启动:确立一个项目或一个项目阶段。项目规划:为完成项目,制定和维护一个可操作的计划。

    支付接入平台结构图

    支付接入平台结构思维导图模板,里面总结了支付接入平台的形式,以及一些长遇见的问题,总结的比较详细。在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。支付系统架构图: 整体上来说,从分层的角度,支付系统和普通的业务系统并没有本质的区别,也是应用、服务、接口、引擎、存储等分层。

    软件测试流程鱼骨图

    软件测试流程: 需求分析,制订测试计划,设计测试用例与编写,实施测试,提交缺陷报告,生成测试总结和报告。软件测试按照研发阶段一般分为5个部分:单元测试、集成测试、确认测试、系统测试、验收测试。

    企业物流管理结构图

    企业物流管理结构图,分析了一个企业从采购,生产,仓储到销售中的流程图。物流管理结构思维导图,主要从物流的概念,采购与供应原理,生产物流管理,仓储与库存管理以及销售几点进行分开阐述。企业物流管理结构图内容包含有物流管理的思维导图,采购管理的思维导图,配送管理的思维导图。

    产品经理职责

    思维导图软件是产品经理十分依赖的工具。产品经理也称产品企划,是指在公司中针对某一项或是某一类的产品进行规划和管理的人员,主要负责产品的研发、制造、营销、渠道等工作。产品经理需要精通产品交互设计的相关流程,包括功能分析、用户角色分析、原型设计、界面开发、易用性测试等。

    产品经理项目管理思维导图

    思维导图可以帮助产品经理梳理多而乱的产品思路,也可以帮助产品经理进行需求管理、产品分析等。产品经理会使用思维导图来对产品的思路进行一个有效的分析,梳理产品逻辑,然后再画原型图。一个优秀的产品经理,不仅仅是会画原型,写需求文档,更重要的是做出用户满意的产品。

    O2O营销结构图

    O2O营销结构思维导图,主要是从用户感觉,产品价值,体验满足以及口碑效应四个方面进行详细说明。o2o营销助力企业实现用户数据中台,智能化运营客户,让获客变得更高效,自动化营销,个性化推荐,数据化运营,实现企业业务转型+创新+增长。

    展开全文
  • 架构的本质是管理复杂性,抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。 最近团队来了一些新人,有些有一定工作经验,是以高级工程师/架构师身份进来的,但我发现他们大部分人...

    转载自:https://blog.csdn.net/wwd0501/article/details/101031156

      


      架构的本质是管理复杂性, 抽象分层分治演化思维是工程师/架构师应对和管理复杂性的四种最基本武器。

    一、抽象思维

      如果要问软件研发/系统架构中最重要的能力是什么,我会毫不犹豫回答是抽象能力。抽象(abstraction)这个词大家经常听到,但是真正理解和能讲清楚什么是抽象的人少之又少。抽象其实是这样定义的:
      对某种事物进行简化表示或描述的过程,抽象让我们关注要素,隐藏额外细节。举一个例子,见下图:img
      你看到什么?你看到的是一扇门,对不对?你看到的不是木头,也不是碳原子,这个门就是抽象,而木头或者碳原子是细节。另外你可以看到门上有个门把手,你看到的不是铁,也不是铁原子,门把手就是抽象,铁和铁原子是细节。
      
      在系统架构和设计中,抽象帮助我们从大处着眼(get our mind about big picture),隐藏细节(temporarily hide details)。抽象能力的强弱,直接决定我们所能解决问题的复杂性和规模大小。

      下图是我们小时候玩的积木,我发现小时候喜欢玩搭积木的,并且搭得快和好的小朋友,一般抽象能力都比较强。 img
      上图右边的积木城堡就是抽象,这个城堡如果你细看的话,它其实还是由若干个子模块组成,这些模块是子抽象单元,左边的各种形状的积木是细节。搭积木的时候,小朋友脑袋里头先有一个城堡的大图(抽象),然后他/她大脑里头会有一个初步的子模块分解(潜意识中完成),然用利用积木搭建每一个子模块,最终拼装出最后的城堡。这里头有一个自顶向下的分治设计,然后自底向上的组合过程,这个分治思维非常重要。
      
      我认为软件系统架构设计和小朋友搭积木无本质差异,只是解决的问题域和规模不同罢了。架构师先要在大脑中形成抽象概念,然后是子模块分解,然后是依次实现子模块,最后将子模块拼装组合起来,形成最后系统。所以我常说编程和架构设计就是搭积木,优秀的架构师受职业习惯影响,眼睛里看到的世界都是模块化拼装组合式的。
      
      抽象能力不仅对软件系统架构设计重要,对建筑、商业、管理等人类其它领域活动同样非常重要。其实可以这样认为,我们生存的世界都是在抽象的基础上构建起来的,离开抽象人类将寸步难行。

      这里顺便提一下抽象层次跳跃问题,这个在开发中是蛮普遍的。有经验的程序员写代码会保持抽象层次的一致性,代码读起来像讲故事,比较清晰易于理解;而没有经验的程序员会有明显的抽象层次跳跃问题,代码读起来就比较累,这个是抽象能力不足造成。举个例子:一个电商网站在处理订单时,一般会走这样一个流程:

    1. 更新库存(InventoryUpdate)
    2. 打折计算(Discounting)
    3. 支付卡校验(PaycardVerification)
    4. 支付(Pay)
    5. 送货(Shipping)

      上述流程中的抽象是在同一个层次上的,比较清晰易于理解,但是没有经验的程序员在实现这个流程的时候,代码层次会跳,比方说主流程到支付卡校验一块,他的代码会突然跳出一行某银行API远程调用,这个就是抽象跳跃,银行API调用是细节,应该封装在PaycardVerification这个抽象里头。

      

    二、分层思维

      除了抽象,分层也是我们应对和管理复杂性的基本思维武器,如下图,为了构建一套复杂系统,我们把整个系统划分成若干个层次,每一层专注解决某个领域的问题,并向上提供服务。有些层次是纵向的,它贯穿所有其它层次,称为共享层。分层也可以认为是抽象的一种方式,将系统抽象分解成若干层次化的模块。 img
      分层架构的案例很多,一个中小型的Spring Web应用程序,我们一般会设计成三层架构: img
      TCP/IP协议栈也是经典的分层架构,如下图: img

      

    三、分治思维

      分而治之(divide and combine或者split and merge)也是应对和管理复杂性的一般性方法,下图展示一个分治的思维流程: img
      对于一个无法一次解决的大问题,我们会先把大问题分解成若干个子问题,如果子问题还无法直接解决,则继续分解成子子问题,直到可以直接解决的程度,这个是分解(divide)的过程;然后将子子问题的解组合拼装成子问题的解,再将子问题的解组合拼装成原问题的解,这个是组合(combine)的过程。

      面试时为了考察候选人的分治思维,我经常会面一个分治题:给你一台8G内存/500G磁盘空间的普通电脑,如何对一个100G的大文件进行排序?假定文件中都是字符串记录,一行约100个字符。
      这是一个典型的分治问题,100G的大文件肯定无法一次加载到内存直接排序,所以需要先切分成若干小问题来解决。那么8G内存的计算机一次大概能排多大的数据量,可以在有限的时间内排完呢?也就是100G的大文件要怎么切法,切成多少份比较合适?这个是考察候选人的时间空间复杂度估算能力,需要一定的计算机组织和算法功底,也需要一定实战经验和sense。
      实际上8G内存的话,操作系统要用掉一部分,如果用Java开发排序程序,大致JVM可用2~4G内存,基于一般的经验值,一次排1G左右的数据应该没有问题(我实际在计算机上干过1G数据的排序,是OK的)。所以100G的文件需要先切分成100份,每份1G,这样每个子文件可以直接加载到内存进行排序。对于1G数据量的字符串排序,采用Java里头提供的快速排序算法是比较合适的。
      好,经过有限时间的排序(取决于计算机性能,快的一天内能排完),假定100个1G的文件都已经排好了,相当于现在硬盘上有100个已经排好序的文件,但是我们最终需要的是一个排好序的文件,下面该怎么做?这个时候我们需要把已经解决的子问题组合起来,合并成我们需要的最终结果文件。这个时候该采用什么算法呢?这里考察候选人对外排序和归并排序算法的掌握程度,我们可以将100个排好序的文件进行两两归并排序,这样不断重复,我们就会得到50个排好序的文件,每个大小是2G。然后再两两归并,不断重复,直到最后两个文件归并成目标文件,这个文件就是100G并且是排好序的。因为是外排序+归并排序,每次只需要读取当前索引指向的文件记录到内存,进行比较,小的那个输出到目标文件,内存占用极少。另外,上面的算法是两路归并,也可以采用多路归并,甚至是采用堆排序进行优化,但是总体分治思路没有变化。
      总体上这是一个非常好的面试题,除了考察候选人的分治思维之外,还考察对各种排序算法(快排,外排序,归并排序,堆排序)的理解,计算的时间空间复杂度估算,计算机的内外存特性和组织,文件操作等等。实际上能完全回答清楚这个问题的候选人极少,如果有幸被我面到一个,我会如获至宝,因为这个人有成长为优秀架构师的潜质。

      

    四、演化思维

      社区里头经常有人在讨论:架构是设计出来的?还是演化出来的?我个人基于十多年的经验认为,架构既是设计出来的,同时也是演化出来的,对于互联网系统,基本上可以说是三分设计,七分演化,而且是在设计中演化,在演化中设计,一个不断迭代的过程。
      在互联网软件系统的整个生命周期过程中,前期的设计和开发大致只占三分,在后面的七分时间里,架构师需要根据用户的反馈对架构进行不断的调整。我认为架构师除了要利用自身的架构设计能力,同时也要学会借助用户反馈和进化的力量,推动架构的持续演进,这个就是演化式架构思维。
      当然一开始的架构设计非常重要,架构定系统基本就成型了,不容马虎。同时,优秀的架构师深知,能够不断应对环境变化的系统,才是有生命力的系统,架构的好坏,很大部分取决于它应对变化的灵活性。所以具有演化式思维的架构师,能够在一开始设计时就考虑到后续架构的演化特性,并且将灵活应对变化的能力作为架构设计的主要考量。

      当前,社区正在兴起一种新的架构方法学~演化式架构,微服务架构就是一种典型的演化式架构,它能够快速响应市场用户需求的变化,而单块架构就缺乏这种灵活性。马丁·福乐曾经在其博客上给出过一张微服务架构的演化路线图[附录8.2],可以用来解释设计式思维和演化式思维的差异,如下图所示: img
      上面的路线是一开始就直奔微服务架构,其实背后体现的是设计式架构的思维,认为架构师可以完全设计整个系统和它的演化方向。马丁认为这种做法风险非常高,一个是成本高昂,另外一个是刚开始架构师对业务域理解不深,无法清晰划分领域边界,开发出来的系统很可能无法满足用户需求。
      下面的路线是从单块架构开始,随着架构师对业务域理解的不断深入,也随着业务和团队规模的不断扩大,渐进式地把单块架构拆分成微服务架构的思路,这就是演化式架构的思维。如果你观察现实世界中一些互联网公司(例如eBay,阿里,Netflix等等)的系统架构,大部分走得都是演化式架构的路线。

      

    五、如何培养架构设计思维

      良好的架构设计思维的培养,离不开工作中大量高质量项目的实战锻炼,然后是平时的学习、思考和提炼总结。
      另外,基本的架构设计思维,其实在我们大学计算机课程(比如数据结构和算法)中可以找到影子,只不过当时以学习为主,问题域比较小和理想化。所以大学教育其实非常重要,基本的架构设计思维在那个时候就已经埋下种子,后面工程实践中进一步消化和应用,随着经验的积累,我们能够解决的问题域复杂性和规模逐渐变大,但基本的武器还是抽象、分层和分治等思维。
      我认为一个架构师的成长高度和他大学期间的思维习惯的养成关系密切。我所知道世界一流的互联网公司,例如谷歌等,招聘工程师新人时,对数据结构和算法的要求可以用苛刻来形容,这个可以理解,谷歌级别公司要解决的问题都是超级复杂的,基本思维功底薄弱根本无法应对。
      对于工作经验<5年的工程师新手,如果你大学时代是属于荒废型的,建议工作之余把相关课程再好好自学一把。个人推荐参考美国Berkeley大学的数据结构课程CS61B[附录8.1]进行学习,对建立抽象编程思维非常有帮助,我本人在研究生阶段自学过这门课程,现在回想起来确实受益匪浅,注意该课程中的所有Lab/Homework/Project都要实际动手做一遍,才有好的效果。

      

    六、小结

      1. 架构的本质是管理复杂性,抽象、分层、分治和演化思维是架构师征服复杂性的四种根本性武器。
      2. 掌握了抽象、分层、分治和演化这四种基本的武器,你可以设计小到一个类,一个模块,一个子系统,或者一个中型的系统,也可以大到一个公司的基础平台架构,微服务架构,技术体系架构,甚至是组织架构,业务架构等等。
      3. 架构设计不是静态的,而是动态演化的。只有能够不断应对环境变化的系统,才是有生命力的系统。所以即使你掌握了抽象、分层和分治这三种基本思维,仍然需要演化式思维,在设计的同时,借助反馈和进化的力量推动架构的持续演进。
      4. 架构师在关注技术,开发应用的同时,需要定期梳理自己的架构设计思维,积累时间长了,你看待世界事物的方式会发生根本性变化,你会发现我们生活其中的世界,其实也是在抽象、分层、分治和演化的基础上构建起来的。另外架构设计思维的形成,会对你的系统架构设计能力产生重大影响。可以说对抽象、分层、分治和演化掌握的深度和灵活应用的水平,直接决定架构师所能解决问题域的复杂性和规模大小,是区分普通应用型架构师和平台型/系统型架构师的一个分水岭。

    展开全文
  • 银行高级架构帅进阶与架构思维拓展培训 课程简介 综合考虑银行数据架构与上层管理分析应用领域 绩效管理风险管理资产负债管理客户与营销分析各 类监管报送与披露下阶段的发展趋势选取其中的几个重点题目主要通过系统...
  • 涵盖了现代前端技术绝大部分的知识内容,起到一个启蒙作用,能帮助读者快速把握前端技术的整个脉络,培养更完善的体系化思维,掌握更多灵活的前端代码架构方法,使读者获得成为高级前端工程师或架构师所必须具备的...
  • 程序员如何提升架构思维?

    思维脑图

    什么是软件架构?

    软件架构就是通过对软件生命周期的拆分,在符合业务架构的前提下,达到软件本身访问增长目的的方式。

    说到软件架构,很多人会认为软件架构就是一堆框架的组合,其实不对,软件架构本身是对于软件实体组织形式的阐述,使用框架的意义是快速完成软件架构设计,而不是取代软件架构设计,两者本质上是不一样的,它们的关系更像是设计图纸和所使用的原材料的关系。

    软件架构离不开软件开发团队的组织架构,这个组织架构是软件开发生命周期和软件运行生命周期的执行者。离开了组织架构,任何软件架构设计都是纸上谈兵,因为架构的核心生命周期就是架构的执行。

    由于软件架构离不开组织架构,那么软件的开发工作在软件公司就形成了工作分工。软件开发工作的分工是经过长期发展而形成的,分工之后形成了不同的工作角色,有人负责收集汇总需求,有人负责编写代码,有人负责执行测试,有人负责上线部署等。

    什么是组织架构?

    软件架构若把软件看成虚拟的人,那软件架构实际上就是虚拟人的组织架构。架构拆分的原则,首先来源于业务自身的组织架构,软件架构要保持和业务组织架构的匹配关系。其实也只有软件架构和组织架构保持匹配,软件架构设计才能真正落地,软件架构师才能真正拥有工作的成就感、归属感。其次来源于软件开发团队自身的组织架构,没有组织架构的软件团队是不存在的,即便是现在流行的扁平化组织架构管理体系,组织架构依然是存在的,只是层级被压缩到较少程度而已。最后来源于用户的流量对软件本身的冲击,这其实是软件模拟人类行为的一种方式,一个人使用和成千上万人同时使用的业务场景都属于正常情况。如果软件开发团队的组织架构和业务的组织架构能一直保持高度一致,内部损耗就会达到最小,软件的架构会更简单,软件架构有效落地的可能性也会大幅度增加,软件模拟人的行为也会更加真实。

    软件架构师岗位

    我们需要有人能够回答下面这些问题。

    • 我们这个系统的边界是什么?

    • 我们系统由哪几部分组成?

    • 各模块之间怎么通信?

    • 选择什么样的基础技术?

    • 为什么要这样选择?

    • 技术方案未来会遭遇哪些坑?

    • 我们的备选方案有哪些?

    • 从技术角度这个应用将来如何持续扩展功能?

    我们开发一套复杂的软件系统需要进行前期规划,对于研发流程来说这个叫总体设计。做任何事情都需要规划,一个复杂的软件更需要规划,如果没有一个良好的设计规划会使后面的维护扩展变得非常艰难。

    很多公司设了软件架构师的职位,主要职责是做出架构设计,他们具备一定的影响力,但并不具备调动组织架构的权利。这样的职位往往不能发挥架构师的作用,有时候还会起反作用。软件架构师必须是一个组织的领导人,有权利调整这个组织的架构,才能够更好地发挥架构师的作用,才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。

    那么,在企业中谁才是真正的架构师?

    一个好的技术领导者就是架构师。

    一个开发团队的领导,如果不能在架构方面给出意见,那就不能在整个设计环节给出自己的观点或者对团队进行指导,也就可能会在整个软件开发流程中脱节,进而丢失自己的技术领导力,也就做不成技术管理者。

    一名优秀的技术管理者,技术在前,管理在后,并不是说两者有太大的轻重差异,而是你需要花费70%的时间在技术上,只能花30%的时间在管理上,但是你需要用这30%的时间做完100%的管理工作。

    当然,也有另一种方式来允许架构师角色独立存在。架构师可以由专门的个人或者团队组成(目前大部分的软件公司的架构师角色都是这样形式),他们承担新技术、框架的调研工作,负责对用户提出的需求进行评估,采用新的技术做出产品原型、输出技术调研报告,供产品部门在技术选型和技术架构选型时参考,这也可以体现架构师的水平和贡献。

    架构师的责任是要把软件生命周期和业务生命周期放在第一位。

    软件生命周期的核心在于软件运行生命周期,以及对软件运行生命周期的拆分和组织。业务生命周期的核心在于对业务的拆分和组织。

    对于软件的生命周期还要考虑软件的开发生命周期,在开发架构上要思考软件架构要如何设计才能支持业务流量的增长。在代码上,要对业务代码和访问代码做好架构拆分,要确保业务代码符合业务的生命周期,使得业务生命周期活动的结果积累在生命周期的主体上,也就是要具有内聚性,避免散落到访问代码中。

    在团队达到一定规模之后,架构师大部分时间需要花费在思考上,也可以继续编程,但是编程的目的是验证架构是否合理,所以不要受是否需要编程这一思维的束缚。如果设计得不好,那么团队就会走很多弯路,如果想要设计得很好,你必须自己或者带领团队做很多的测试、预研工作。

    软件架构的思路

    要做好软件架构,首先是要学会拆分生命周期(软件生命周期和业务生命周期),并且有能力去指导企业形成相应的组织架构来落实软件架构的实施。软件架构是服务于业务的,因此架构师无法去直接调整业务利益的,只能够在某种程度上去影响。

    架构师的目的是为了应对增长,而要达到增长,所以架构师应该把需要增长的业务了解清楚,挖掘出核心生命周期,并确定核心生命周期的主体。换句话说架构师要发现问题的主体,并确定核心问题。在确定业务核心生命周期以及核心生命周期的主体之后,架构师还需要对业务核心生命周期进行分析,剥离出非核心生命周期,并根据当前人员的状况,合理地分配非核心生命周期的权责。这样不同的人就可以并行且互不影响地做不同的事情,最后根据核心生命周期,把他们的工作成果组合起来,达到1+1>2的效果。

    架构师绩效的反馈应该由问题的解决效果来决定。如果以很少的资源达到了很大的业务增长,那肯定是一位好的架构师,公司所节省下来的资源应该回馈给架构师,从而形成正向反馈。

    如何培养架构能力?

    提升驱动力

    对于一个技术团队要提升系统架构能力,首先必须要有自己的技术定位,要有浓厚的技术氛围、明确的技术愿景,只有这样才能留得住热爱技术的工程师。其次是要制定团队技术能力的提升计划,特别是系统架构能力的提升。而提高系统架构能力往往又需要实际的推动力,推动力一般来自三方面。

    • 客户的实际需求。比如客户要求系统能支持1万并发请求,但实际压测仅支持1000,那这时候要进行技术改进,局部改进或者重构。阿里的双11就是阿里技术发展的强大推动力。

    • 测试数据。比如在进行性能测试时发现一个测试数据很诡异,首先想到可能是数据库问题,为什么操作数据库花费了这么多时间?然后是算法或者逻辑的问题。业务发展到一定阶段都会遇到“飞机在全速飞行的前提下换引擎”的问题,是在现有框架下对两个业务分别改造,还是推翻现有模式建立一个技术共享的新模式?这不仅是对架构能力的挑战,更是对团队的协同作战能力的考验。

    • 外部公司技术资料。例如参加顶尖科技公司主办的技术大会、顶尖科技媒体主办的技术交流会,或者阅读技术大牛公司或者个人出版的图书、IEEE论文等,这些都能给技术管理者一些灵感,帮助他们创造更好的技术产品。多了解外部的技术发展状态,对于明确或纠正团队的技术发展方向很有利。

    技术团队需要不断地前进,作为技术人员的我们也要学会给自己设置技术愿景,只有不断给自己设置愿景的人,才会不断地尝试提高自己的技术能力、设计能力。

    步步为营

    我们需要一步一步地走,好的架构都不是一蹴而就的,而是一步步完善的。

    以一个电商架构的演进为例,一个电商站点刚开始时流量不高,只需要一个单体架构就能支持了。

    随着网站曝光率越来越大,流量上来了,为了应对流量,这时候可以做集群进行流量分散,以承载更多流量。

    一段时间过去了,流量变得更大了,我们需要做进一步的架构优化,进行数据库读写分离。

    好了,流量继续增加,为了提高性能,我们要引入缓存来优化了。

    网站曝光量越来越大,数据量越来越大,考虑进行分库分表。

    流量还在持续增大,这时候要考虑进行微服务拆分了。

    从这个例子可以看到,架构模式是随着业务需求的变化而不断变化演进的,这也和上面我们说的业务需求的驱动力是相对应的。

    从一个程序员到架构师是一个很大的变化,架构师需要从大的方面考虑,而不只是考虑这个模块该用哪种设计模式去开发。总的来说,想要成为架构师,需要有耐心,不断学习,拓宽自己的视野,不要局限于自己眼前的项目,多关注开源技术,多关注热门技术社区的新动向。

    创新思维

    批判性思维是创新过程中最显著的特征。

    什么是批判性思维?批判性思维是通过否定来寻找更好的做事方法。

    程序员应该要拥有一定的批判性思维。

    创新的4个核心要素:

    • 批判性思维则是通过否定来寻找更好的做事方法。

    • 批判性思维需要准确的问题定义。

    • 问题的定义有赖于概念系统的建立。

    • 在初始阶段,概念模型的正确与否是次要的,更为重要的是要有一个概念模型,然后这个概念模型可以随着认识的深入而不断演化。

    这期的架构思维就聊到这,篇幅比较长,希望大家读完也能有所共鸣。

    我是Seven,一个不懈努力的程序猿,希望本文能对你有所裨益

    为什么说在西游记项目组里沙僧最容易被开除?

    如何看懂Apache Log4j 远程代码执行漏洞原理?

    细数Java8-14的那些经典特性,语言的车轮正在滚滚向前...

    要使用消息队列,以下这些你都要知道...

    GC如何判断一个对象是否为垃圾?深度剖析三色标记算法原理

    是什么决定了一个项目是否成功?

    Seven的代码实验室

    一只不懈努力的程序猿,通过代码实验洞悉技术的本质。

    展开全文
  • 系统架构思维导图

    2018-10-11 16:42:37
    以下是对大型系统架构进行的总结,其内容包括 1 系统架构技术总览 2大型网站架构特点 3网站演化过程 4网站架构模式 5架构要素 6 系统瞬时响应 7 网站的高可用架构 8 网站监控  9 伸缩性架构 10 系统可...
  • mysql架构思维导图
  • 四种核心架构思维

    万次阅读 多人点赞 2019-02-11 11:56:35
    架构的本质是管理复杂性,抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。 最近团队来了一些新人,有些有一定工作经验,是以高级工程师/架构师身份进来的,但我发现他们大部分人...
  • 架构思维其实就那么回事.pdf
  • 大数据在企业管理架构思维的运用.docx
  • 本文不仅展示的Kafka分区迁移实战,更是体现一位架构师面面对线上故障做架构方案的设计思维
  • 思维导图 知识架构思维导图
  • JAVA教学中软件分层架构思维方式的引导
  • JAVA教学中软件分层架构思维方式的引导.pdf
  • 由几位行业技术大咖共同编写的《人人都要学的架构思维》电子书,包含:阿里、京东、字节、美团等大厂的架构案例。现在公开出来,供大家下载学习。这是电子书目录截图:(电子书截图)电子书的获取方式:...
  • 微服务之核心架构思维

    千次阅读 2018-05-31 10:35:29
    一、介绍架构的本质是管理复杂性,抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。最近团队来了一些新人,有些有一定工作经验,是以高级工程师/架构师身份进来的,但我发现他们大...
  • 架构设计本质-架构思维 加油站:如果你想攀登高峰,彩虹一定不是最好的梯子; 前言: 本篇文章结合多数人在工作中的模块开发,架构设计情况,以及相关权威性文章和书籍,总结下如何在开发过程中,慢慢养成架构思维,...
  • 微服务架构思维导图

    千次阅读 2019-03-11 17:51:15
    根据阿里技术专家李云华老师的课程《从0开始学架构》中微服务的介绍,总结的思维导图。希望能让大家对微服务有个大致的把握。
  • 一个优秀的架构师,往往都是能够不断成长的,但是不断成长却需要固定的架构思维培养方式。从基本的知识输入到架构流程脑裂再形成最终的方案输出,这种闭环思维才是架构师的最好的成长方式。 输入 接触到的架构快速...
  • 文末有相关对应专题的讲解资料,和高清的思维图谱,有需要的可以去领取。 开源框架解析 spring5概述 Spring5 Framework体系结构 Spring5环境搭建 IOC源码解析 AOP源码解析 Spring MVC Mybatis 微服务架构专题 服务...
  • PHP技能架构思维导图详解apache思维导图js正则表达式LAMPer技能树MongoDB操作手册mysql数据库优化mysql学习思维导图NoSQL分布式模型PHP基础PHP面向对象PHP涉及到编程知识PHP学习目录大型网站技术架构大型网站提速...
  • ITIL V3架构思维导图

    2017-04-18 17:20:34
    根据ITIL V3整理的导图,希望对大家有用,根据学习所得绘制而成,更加清晰明了的了解ITIL整体架构和理念
  • 看完了“李智慧”老师的《大型网站技术架构-核心原理与案例分析》一书,让我对大型网站的技术架构所遇到的问题,所考虑到的内容,所用到的解决方案有了一个初步的认识。任何的大型网站都是从一个小网站发展而来的,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 149,606
精华内容 59,842
关键字:

架构思维