网站首页
您现在的位置:主页 > 平肖固定算法公式 >
栏目导航
热门新闻

如何成为一个架构师?

发布日期:2020-06-04 03:41   来源:未知   阅读:

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

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

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

  IT 架构师-应用架构师:专注于结合企业需求,定制化 IT 解决方案;大部分需要交付的工作包括总体架构、应用架构、数据架构,甚至部署架构。

  IT 架构师-技术架构师:专注于基础设施,某种软硬件体系,甚至云平台,提交:产品建议、产品选型、部署架构、网络方案,甚至数据中心建设方案等。

  阿里内部没有在职位 title 上专门设置架构师了,架构师更多是以角色而存在,现在还留下可见的 title 有两个:首席架构师和解决方案架构师,其中解决方案架构师目前在大部分 BU 都有设置,特别是在阿里云和电商体系。

  架构师职责明确了,那么有什么架构思维可以指导架构设计呢?请看下述的架构思维。

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

  3.问题定义中,需要对问题进行升层思考后再进行升维思考,从而真正抓到问题的本质,理清和挖掘清楚需求;要善用第一性原理思维进行分析思考问题。

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

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

  6.对我们的现有的流程和能力模型进行梳理,找到需要提升的地方,升层思考和升维思考线.定义指标,并能够对指标进行拆解,然后进行数学建模。

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

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

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

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

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

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

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

  有了架构思维的指导,具体有没有通用/标准化的架构框架以更好的执行架构设计?请看常见的架构框架。下述的架构框架其实本身也包含了重要的一些架构思维。

  TOGAF 强调商业目标作为架构的驱动力,并提供了一个最佳实践的储藏库,其中包括 TOGAF 架构开发方法(ADM)、TOGAF 架构内容框架、TOGAF 参考模型、架构开发方法(ADM)指引和技术、企业连续统一体和 TOGAF 能力框架。

  第一个最有影响力的框架方法论就是 Zachman 框架,它是 John Zachman 首次在1987年提出的。

  Zachman 框架模型分两个维度:横向维度采用6W(what、how、where、who、when、why)进行组织,纵向维度反映了 IT 架构层次,从上到下(Top-Down),分别为范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。横向结合6W,Zachman 框架分别由数据、功能、网络、人员、时间、动机分别对应回答What、How、Where、Who、When 与 Why 这六个问题。

  DODAF 是美国国防部架构框架,是一个控制“EA开发、维护和决策生成”的组织机制,是统一组织“团队资源、描述和控制EA活动”的总体结构。

  DODAF 涵盖 DoD 的所有业务领域,定义了表示、描述、集成 DoD 范围内众多架构的标准方法,确保架构描述可比较、评估,提供了对 FoS (系统族)和 SoS (体系)进行理解、比较、集成和互操作共同的架构基础,提供开发和表达架构描述的规则和指南,但不指导如何实现。

  与所有视点相关的体系结构描述的顶层概貌。提供有关体系结构描述的总体信息,诸如体系结构描述的范围和背景。范围包括体系结构描述的专业领域和时间框架。背景由构成体系结构描述背景的相互关联各种条件组成,包括条令,战术、技术和程序,相关目标和构想的描述,作战概念(CONOPS),想定和环境条件。

  能力视点(CV)集中反映了与整体愿景相关的组织目标,这些愿景指在特定标准和条件下进行特定行动过程或是达成期望效果的能力,它们综合使用各种手段和方式来完成一组任务。

  CV 为体系结构描述中阐述的能力提供了战略背景和相应的高层范围,比作战概念图中定义的基于想定的范围更全面。

  这些模型是高层的,用决策者易于理解的术语来描述能力,以便沟通能力演进方面战略构想。

  作战视点(OV)集中反映了完成 DoD 使命的机构、任务或执行的行动以及彼此间必须交换的信息。描述信息交换的种类、频度、性质,信息交换支持哪些任务和活动。

  服务视点(SvcV)集中反映了为作战行动提供支撑的系统、服务和相互交织的功能。DoD 流程包括作战、业务、情报和基础设施功能。SvcV 功能和服务资源及要素可以链接到 0V 中的体系结构数据。这些系统功能和服务资源支撑作战行动,促进信息交换。

  系统视点(SV)集中反映支持作战行动中的自动化系统、相互交联和其他系统功能的信息。随着对面向服务环境和云计算的重视,在 DoDAF 的未来版本中也许不会有系统视点。

  数据和信息视点(DIV),简称数信视点,反映了体系结构描述中的业务信息需求和结构化的业务流程规则。

  标准视点(StdV)是用来管控系统各组成部分或要素的编排、交互和相互依赖的规则的最小集。其目的是确保系统能满足特定的一组操作需求。

  标准视点提供技术系统的实施指南,以工程规范为基础,确立通用的积木块,开发产品线。

  包括一系列技术标准、执行惯例、标准选项、规则和规范,这些标准在特定体系结构描述中可以组成管控系统和系统/服务要素的文件(profile)。

  项目视点(PV)集中反映了项目是如何有机地组织成一个釆办项目的有序组合。

  设计原则有很多,我们进行架构设计的主导原则是 OCP(开闭原则),在类和代码的层级上有:SRP(单一职责原则)、LSP(里氏替换原则)、ISP(接口隔离原则)、DIP(依赖反转原则);在组件的层级上有:REP(复用、发布等同原则)、CCP(共同闭包原则)、CRP(共同复用原则),处理组件依赖问题的三原则:无依赖环原则、稳定依赖原则、稳定抽象原则。

  :设计良好的软件应该易于扩展,同时抗拒修改。这是我们进行架构设计的主导原则,其他的原则都为这条原则服务。

  :任何一个软件模块,都应该有且只有一个被修改的原因,“被修改的原因“指系统的用户或所有者,翻译一下就是,任何模块只对一个用户的价值负责,该原则指导我们如何拆分组件。举个例子,CTO 和 COO 都要统计员工的工时,当前他们要求的统计方式可能是相同的,我们复用一套代码,这时 COO 说周末的工时统计要乘以二,按照这个需求修改完代码,CTO 可能就要过来骂街了。当然这是个非常浅显的例子,实际项目中也有很多代码服务于多个价值主体,这带来很大的探秘成本和修改风险,另外,当一份代码有多个所有者时,就会产生代码合并冲突的问题。

  :当用同一接口的不同实现互相替换时,系统的行为应该保持不变。该原则指导的是接口与其实现方式。你一定很疑惑,实现了同一个接口,他们的行为也肯定是一致的呀,还真不一定。假设认为矩形的系统行为是:面积=宽*高,让正方形实现矩形的接口,在调用 setW 和 setH 时,正方形做的其实是同一个事情,设置它的边长。这时下边的单元测试用矩形能通过,用正方形就不行,实现同样的接口,但是系统行为变了,这是违反 LSP 的经典案例。

  :不依赖任何不需要的方法、类或组件。该原则指导我们的接口设计。当我们依赖一个接口但只用到了其中的部分方法时,其实我们已经依赖了不需要的方法或类,当这些方法或类有变更时,会引起我们类的重新编译,或者引起我们组件的重新部署,这些都是不必要的。所以我们最好定义个小接口,把用到的方法拆出来。

  :指一种特定的解耦(传统的依赖关系创建在高层次上,而具体的策略设置则应用在低层次的模块上)形式,使得高层次的模块不依赖于低层次的模块的实现细节,依赖关系被颠倒(反转),从而使得低层次模块依赖于高层次模块的需求抽象。跨越组建边界的依赖方向永远与控制流的方向相反。该原则指导我们设计组件间依赖的方向。

  依赖反转原则是个可操作性非常强的原则,当你要修改组件间的依赖方向时,将需要进行组件间通信的类抽象为接口,接口放在边界的哪边,依赖就指向哪边。

  :软件复用的最小粒度应等同于其发布的最小粒度。直白地说,就是要复用一段代码就把它抽成组件,该原则指导我们组件拆分的粒度。

  <(共同闭包原则)

  :为了相同目的而同时修改的类,应该放在同一个组件中。CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。对大部分应用程序而言,可维护性的重要性远远大于可复用性,由同一个原因引起的代码修改,最好在同一个组件中,如果分散在多个组件中,那么开发、提交、部署的成本都会上升。

  :不要强迫一个组件依赖它不需要的东西。CRP 原则是 ISP原则在组件层面的描述。该原则指导我们组件拆分的粒度。相信你一定有这种经历,集成了组件 A,但组件 A 依赖了组件 B、C。即使组件 B、C 你完全用不到,也不得不集成进来。这是因为你只用到了组件 A 的部分能力,组件 A 中额外的能力带来了额外的依赖。如果遵循共同复用原则,你需要把 A 拆分,只保留你要用的部分。

  REP、CCP、CRP 三个原则之间存在彼此竞争的关系,REP 和 CCP 是黏合性原则,它们会让组件变得更大,而 CRP 原则是排除性原则,它会让组件变小。遵守REP、CCP 而忽略 CRP,就会依赖了太多没有用到的组件和类,而这些组件或类的变动会导致你自己的组件进行太多不必要的发布;遵守 REP、CRP 而忽略 CCP,因为组件拆分的太细了,一个需求变更可能要改 n 个组件,带来的成本也是巨大的。

  :应该提供控制具体功能是否可用的配置,在系统出现故障时能够快速下线.监控设计:在设计阶段就要考虑监控的手段,便于有效的排查问题,比如引入traceId、业务身份 Id 便于排查监控问题;

  5.多活数据中心设计:若系统需要极高的高可用,应考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用;

  6.采用成熟的技术:刚开发的或开源的技术往往存在很多隐藏的 bug,出了问题没有很好的商业支持可能会是一个灾难;

  9.非核心则购买的原则:非核心功能若需要占用大量的研发资源才能解决,则考虑购买成熟的产品;

  11.快速迭代:系统应该快速开发小功能模块,尽快上线进行验证,早日发现问题大大降低系统交付的风险;

  12.无状态设计:服务接口应该做成无状态的,当前接口的访问不依赖于接口上次访问的状态。

  架构师知道了职责,具备很好的架构思维,掌握了通用的架构框架和方法论,使用架构原则进行架构设计,不同的业务和系统要求不一样,那么有没有针对不同场景的系统架构设计?下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍,以便于我们在实际运用中进行参考使用。

  说明:好景不长,发现随着系统访问量的再度增加,webserver 机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台 webserver。

  说明:系统访问特点遵循二八定律,即80%的业务访问集中在20%的数据上。缓存分为本地缓存 远程分布式缓存,本地缓存访问速度更快但缓存数据量有限,同时存在与应用程序争用内存的情况。

  说明:在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了。突然有一天,发现系统的访问又开始有变慢的趋势了,这个时候首先查看数据库,压力一切正常,之后查看 webserver,发现apache 阻塞了很多的请求, 而应用服务器对每个请求也是比较快的,看来是请求数太高导致需要排队等待,响应速度变慢。

  说明:享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢。

  说明:随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作

  描述:为了应对日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分成不同的产品线,应用之间通过超链接建立关系,也可以通过消息队列进行数据分发,当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

  纵向拆分:将一个大应用拆分为多个小应用,如果新业务较为独立,那么就直接将其设计部署为一个独立的 Web 应用系统纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离即可。

  1、什么是单元化:单元化架构是从并行计算领域发展而来。在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含的安装。而一个分区(Shard),则是整体数据集的一个子集,如果你用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。

  2、单元化的必要性:随着硬件的不断升级,计算机硬件能力已经越来越强,CPU越来越快,内存越来越大,网络越来越宽。这让我们看到了在单台机器上垂直扩展的机会。尤其是当你遇到一个性能要求和容量增长可以预期的业务,单元化给我们提供另外的机会,让我们可以有效降低资源的使用,提供更高性能的服务。

  更高性能更低成本是我们的主要目标,经过单元化改造,我们得以用更少(约二分之一)的机器,获得了比原来更高(接近百倍)的性能。性能的提升很大部分原因在于服务的本地化,而服务的集成部署又进一步降低了资源的使用。除了性能收益,还有很多收益,比如更好的隔离性,包括请求隔离和资源隔离,比如更友好的升级,产品可以灰度发布等。单元化改造后对高峰的应对以及扩容方式等问题的解决。

  在单元化架构下,服务虽然分层划分,但每个单元自成一体。按照层次来讲的话,所有层使用相同的分区算法,每一层都有相同数量的节点,上层节点也会访问指定的下层节点。

  SOA(Service-Oriented Architecture,面向服务的架构)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

  SOA的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标,就要在实施 SOA 的过程中牢记以下特征:

  (6)服务接口设计管理(7)标准化的服务接口(8)支持各种消息模式(9)精确定义的服务契约为了实现 SOA,企业需要一个服务架构,下图显示了一个例子:>

  在上图中, 服务消费者(service consumer)可以通过发送消息来调用服务。这些消息由一个服务总线(service bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引(business rules engine),该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(service management infrastructure),用来管理服务,类似审核,列表(billing),日志等功能。此外,该架构给企业提供了灵活的业务流程,更好地处理控制请求(regulatory requirement),例如Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。

  所有的功能打包在一个 WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI 等所有逻辑。

  1、思想:无服务器是一种架构理念,其核心思想是将提供服务资源的基础设施抽象成各种服务,以 API 接口的方式供给用户按需调用,真正做到按需伸缩、按使用收费。

  2、优势:消除了对传统的海量持续在线服务器组件的需求,降低了开发和运维的复杂性,降低运营成本并缩短了业务系统的交付周期,使得用户能够专注在价值密度更高的业务逻辑的开发上。

  3、内容:目前业界较为公认的无服务器架构主要包括两个方面,即提供计算资源的函数服务平台 FaaS,以及提供托管云服务的后端服务 BaaS。

  函数即服务(Function as a Service):是一项基于事件驱动的函数托管计算服务。通过函数服务,开发者只需要编写业务函数代码并设置运行的条件,无需配置和管理服务器等基础设施,函数代码运行在无状态的容器中,由事件触发且短暂易失,并完全由第三方管理,基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行,并且按实际执行资源计费,不执行不产生费用。

  后端即服务(Backend as a Service):BaaS 覆盖了应用可能依赖的所有第三方服务,如云数据库、身份验证、对象存储等服务,开发人员通过 API 和由 BaaS 服务商提供的 SDK,能够集成所需的所有后端功能,而无需构建后端应用,更不必管理虚拟机或容器等基础设施,就能保证应用的正常运行。

  Applicationless 对应的是服务发布,在服务化框架下,你的服务发布不再需要申请应用,也不需要关注你的应用在哪。

  Serverless 对应的则是服务运维,有了 Serverless 化能力,你不再需要关注你的机器资源,Servlerless 会帮你搞定机器资源的弹性扩缩容。

  架构师在完成上述架构设计后,最终是需要协同利益相关方一起按项目化运作落地拿结果,那么应该如何保证利益相关方在项目落地的满意度,如何保证按照架构很好的拿到项目成功的结果呢?架构管理能力是架构师非常重要的能力。

  声明:本文部分内容参考阿里内部和外部一些文章,详情见上述参考资料;撰写本文的重点是系统体系化地总结认识架构师的工作,以便于更好的互动学习和成长,部分观点是个人观点。本文作者: 九摩

  阿里妹导读:毕玄是阿里巴巴资深技术专家,07年加入阿里,一手打造了HSF,十多年来更见证参与了阿里在基础技术上的演进与发展。他觉得系统设计是远比 Java 编程技能更难的培训,很容易变成务虚课。为了挑战难题,毕玄决定大胆尝试在内部搞了个民间培训。于是就有了今天的文章,希望这些深入浅出的解读能给架构师们带来一些收获。

  本文转自毕玄老师个人公众号:hellojavacases(不常更新,一更就是经典)

  系统设计我一直觉得是远比Java编程技能更难多了的培训,很容易变成务虚课,全是一堆理论,所以,以前从来不敢尝试做这方面的培训,今年由于一些情况,决定大胆尝试下,就在内部搞了个民间的培训,还真有不少同学捧场。在开始上这门课后,我觉得收获最大的搞不好是我自己,整理思路,从和学员的互动中学习到了很多,能更好地对系统设计的一些方法论进行抽象总结,所以我对这些捧场的学员们说:其实是我们一起在共创系统设计的课程 。

  通过这堂课掌握一个思考框架,知道做系统设计的套路,系统设计不是简单的上来就画画框什么,必须按照一定的套路才能更好的进行系统设计;

  拓宽知识面,系统设计中非常重要的是考虑的全面性,以更好的进行权衡取舍,所以能不能借助系统设计培训来拓宽知识面非常重要。

  而要达到这样的效果,怎么去上这堂课挑战其实是不小的:想要传达的思考框架到底是什么?怎么样变成不是纯粹的理论,务虚的传达,从而让大家能更好的掌握并真正的去运用这个思考框架?以前真的没仔细的思考过系统设计的思考框架的问题,其实吧很多的系统设计的模板就是一个思考框架,但在不理解的情况下,是很难应用好的。

  另外,还有很重要的一点是,一个大架构师是需要给很多人讲解系统设计的,只有理解并讲清了系统设计的目的,团队才能更好的去实现。

  在核心设计的这个阶段中,会产生一些新的衡量设计最后实现情况的目标,这些也都要增加到系统设计中,确保最后的实现和设计的偏差度是可视的。

  ps: 这就是做分享/培训的好处,借机仔细整理自己的碎片,从而形成体系。

  作为系统设计的第一步,重要性毋庸置疑,如果连系统建设的目的都没搞清楚,后面所有的步骤都会错误。如果我们去看很多的系统设计,会发现压根就没有系统建设的目的的仔细分析。

  当需要做系统设计时,就意味着需要建设一套新系统,或者对原有的系统进行比较大的架构的改造升级,这一定是基于什么原因才要去做的。之所以要分析好系统建设的目的,

  一方面是为了避免出发点有问题,系统建设的目的应该是充分反映出解决业务层面临的挑战,

  从对系统建设的目的的分析中,是很容易看出格局和高度的,这两个词看起来非常虚,但其实很实,格局和高度通常是指所做的事影响的范围大小,例如从所在的一个小团队,到所在的大部门,到所在的大BU,到所在的大BG,到跨多BG的业务板块,到整个集团,甚至是到这个社会,这里一定要实事求是,别这里讲的是世界形势,后面的整个系统设计又完全解决不了这里所说的。结合我自己的经历来说,在早期做HSF时,在系统建设的目的这点上是最为缺失的,也导致了自己在HSF阶段犯下了几次大的错误,例如最典型的就是HSF做动态化的那次系统架构改造,如果仔细的去分析当时做这件事的目的,就会看到这个是出于技术情怀,而不是业务端面临的业务挑战,或者说HSF的用户面临的问题,也就是之前说的出发点的问题,我觉得这是很多技术人员非常容易犯的错误,就是纯粹是出于技术诉求发动的很大动作的系统重构,我自己是在有一年有一位阿里的高管在给我做辅导时,提到首先要思考清楚为什么做某件事,并且能讲清楚原因,才明白了动机真的是非常重要的,后面做事的时候才能没那么技术化了。

  总得来说,我认为做系统设计前,一定要先对于系统建设的目的分析清楚,确保系统建设有价值和有意义,同时确保后面的整个系统设计是能让目的达成的。

  第一个是2011年做容器化,建设这套系统的目的是为了应对预计会越来越大的机器成本,目标相应的制定为支撑相同的业务量,机器下降一半。

  第二个是2013年做异地多活,建设这套系统的目的是为了能够让业务具备更强的抵御灾害的能力,尽管后面发现因为有了异地多活,有了更多的好处,但那些确实在系统设计之初是完全没放在建设目的里的,后面能做到纯属巧合,例如因为有了异地多活使得后面的弹性借助云资源成为了现实,因为有了异地多活,基础设施技术的演进可以更加快速,在设计之初根据目的相应制定的目标为业务能够部署在中国多个地点(地点间距离1千公里),多个地点部署的业务都处于承接流量的状态,且流量从A点切换到B点能在30s内完成。

  更重要也是最容易遗漏的一点,是可以做一个用来跟踪系统建设效果的系统,例如之前做容器化,我们会有一个展示,是容器化后的集群多少机器支撑了多少的业务量,和目前还未容器化的集群的一个对比;异地多活,会有一个管控系统,用来展示系统的部署情况,以及流量切换。只有有了跟踪系统建设目标是否达标的系统,才能真正确保系统建设完毕后和初心保持了一致,否则很多系统建设的时候是一个目的,最后做完了是另外的状况,所以这个跟踪效果的体系是一定要在系统建设的时候同步就做好的。

  如果要达成系统设计的可衡量的目标,到底面临了一些什么核心问题,只有明白了面临什么核心问题,才能更加明确的进行系统设计来解决这些问题。

  最开始做HSF的时候,为什么要做HSF是比较清晰的,在可衡量的目标上也有一个大概的要支持每条上亿的服务调用,但由于当时的技术功底问题,导致了在提炼核心问题上是有很大差距的,这些也造成了后来HSF总是不断的重构、修修补补之类。所以,我从来就不认为技术功底不好的人能做好一个架构师,架构师绝对不是看到的随手画几个框那么简单,那通常只是个结果,但要合理的把框画出来是需要基于非常坚实的技术功底,HSF在最初设计时认为的核心问题就是怎么实现一个易用有服务定义的RPC框架,但对于如何支撑好上亿的交互调用量,服务化上线后给业务研发会带来什么问题(例如排查问题变复杂了),在核心问题上是有很大的缺失的,例如HSF上线后才发现的中间的负载均衡的问题,而这个问题是导致了HSF结构重新设计的,这个后来回头看就会发现如果是一个知识面更广的架构师可能一开始就会想到这个核心问题,所以如果回过头去看,HSF这样的框架,要达成目标,要解决的核心问题应该是:

  在做T4(容器)的时候,目的、目标都还比较清晰,问题的提炼现在回顾也做的还ok,T4要解的核心问题为如何实现在一台机器上跑20个应用,T4出现的问题更多是对于核心问题的设计方案上,这个到下篇讲围绕核心问题的系统设计上再写。

  到了做异地多活的时候,目的、目标的清晰化都ok,对于异地多活而言,要做到在中国多个城市都可同时支撑流量,并且可在几十秒内完成流量切换,异地多活中物理距离所带来的网络延时是不可突破的,怎么做到多地活且流量可动态切换,要做到这个,面临的核心问题是:

  如何尽可能扩大统一的资源池,解决资源池统一面临的资源竞争、资源被抢、多种不同资源规格等问题?

  继前面的系统建设的目的、可衡量的目标,达成目标的核心问题后,进入到解决核心问题的设计环节了,技术人员其实最擅长的是直奔这个主题,而且估计更期盼的也是这篇,有些时候会导致跳过前面的目的、目标环节,导致最终做出来的系统要么没贴合业务挑战,要么嘛偏离了做这个系统的初衷,所以我仍然强烈建议做系统设计的同学不要着急,一步一步来。

  继续结合自己的cases来讲讲解决核心问题的设计这个环节,回顾自己的cases,犯了不少的错误,也碰到了非常多复杂的权衡选择的状况,才逐渐更加明白一个架构师应该具备的一些能力。

  易用这点在第一个版本犯了错,不过还好是第一个版本,否则纠正错误的代价会无比巨大,那个版本里,如果要把一个spring的bean发布为HSF服务,或者调用一个HSF服务,需要写一个文件,在文件里描述发布的服务和调用的服务,并且在这个文件放在jboss的某个目录里,这个方式看起来对在写代码的过程中完全没有侵入,但导致的巨大问题是这文件放在哪里写,写完后部署的阶段怎么自动放到对应的目录去,在第二个版本里才把这个调整为用一个Spring Bean的方式来做服务的发布和调用,尽管这一定程度导致了业务代码需要有对HSF的明显的依赖,但对维护、部署等都变的很标准,所以从这里可以看到,设计是全方位的,要考虑到的不仅仅是怎么实现,还有别人怎么用,运行、维护阶段又是怎么样的。

  HSF犯的第二个错,就是在能支撑每天上亿次服务调用的RPC框架这点上,是给我自己代码生涯最大的教训,甚至彻底改变了我之后做设计时的技术选型风格。在做HSF之前,我从来没做过一天访问量超过100w的系统,完全搞不清一个每天上亿次的系统到底有什么不同,HSF最早的版本在通讯框架上选择了JBoss-Remoting,原因也其实比较简单,因为我们用的Web容器是JBoss,结果这个版本在一个非常重要的系统上线时,出现了严重的故障,导致了整个网站的响应速度都变的很慢。当时查了几乎整整一天都没查出原因到底是什么,后来回滚恢复,所以可以肯定是HSF上线造成的,等到回滚后的一个星期内才查出原因,是因为JBoss-Remoting在调用远端时,默认的超时时间为60s,而我们后端的那个系统在处理某些服务的时候会特别慢,进而导致了共用的处理线程池满了,所以整个网站的表现就变慢了。

  这次问题让我彻底明白了访问量大的系统最重要的是对整个系统的处理过程要非常的清楚,因为在访问量大的情况下,一些小的问题有可能会放大成很大的问题,进而到故障,所以访问量大的系统对技术的可控性要求是极高的,这也是最大的不同,可控性并不代表一定要完全自己写,但要求如果用到开源的东西,要对开源的东西的代码逻辑非常熟悉,为了解决上面的问题,HSF基于Mina写了一个自己版本的通讯框架,自己来处理连接方式、线程池等,后面在做各种HSF改造,以及其他技术改造时,基本都遵循了技术可控性这个原则。

  在负载均衡这点上,在早期版本里,是通过硬件负载均衡设备来做的,这里造成了好几个问题,一是需要先配置要调用的服务的vip地址,当然,这可以通过一个中央的配置服务器之类的方式,第二个是HSF采用的是长连接的方式,通过vip去连接后端的一个集群时,这里会出现非常麻烦的问题,例如后端集群发布重启,很有可能就会造成连接的极度不均衡,进而导致故障。

  除了上面两个问题后,还有一个触发HSF去做改造的原因是当时的硬件负载设备出现了流量跑满的现象,而这是必须要经过的一个点,会造成全站全部崩溃,不希望在未来系统中有个这么大的高风险的集中点,再加上上面的两个问题,决定做彻底的改造,于是HSF开始设计了目前看起来在服务框架体系中非常经典的软件方式的服务注册、发现和寻址的结构。

  在负载均衡这件事上,现在回顾也可以看出这个仍然是当初对一个访问量巨大的系统考虑不够全面造成的。

  在服务化后会带来的排查问题这点上,当初设计的时候更是完全没有考虑到,导致了后面排查问题效率低、人力投入大等等问题,后来为了解决这个问题,学习了Google家Dapper的思想,但花了很长时间这东西才真正落地。

  除了上面这些外,HSF其实还有各种设计问题,例如最早的通讯协议里竟然是没有版本号的,导致后面升级时处理兼容的复杂,又例如更麻烦的一个话题就是在多语言支持上。

  HSF作为我第一个真正做的访问量巨大且核心的系统的设计,由于当初的技术功底,犯下了无数错误,导致了N次返工、故障和弥补,当然也让自己得到了很大的成长,这几年回过头想这个问题,越来越觉得必须无比感谢我当时的主管对我巨大的包容和支持,HSF的经历,让我在解决核心问题的设计这个环节上,明白的是作为一个架构师,在技术选型上深厚的技术功底,在整个设计方案上知识的广度,考虑的全面性(从开发态、部署态、运行态和运维态)都是要求极高的。

  为了做到在一台机器上能比以前用虚拟机的方式运行更多的应用进程,最早我们采用的方法是各种hack,其实要实现的就是进程级隔离,结果就是hack到了一定程度后,确实勉强能用了,但上线了一些小范围,有了一些用户后,发现我们的hack是很难枚举的,非常痛苦,直到有一天“发现”了LXC,才走对了路线。

  除了上面这个选型层面的问题外,T4的过程中还碰到过很多类似的问题,例如用什么方法去控制磁盘空间的限制,最早我们也是用的同样的image的方式,但image的方式对磁盘空间超卖其实是非常不友好的,后来为了把这个方案更换成dir quota的方案,一帮人几乎是连续折腾了一个多月,因为线上已经在运行的要通过cp文件等方法来弄。

  HSF的那段看到的很多是在技术深度上的问题,而T4的这段设计,现在回顾最主要的问题是这个技术领域视野的严重问题,所以我认为作为架构师,在相应的技术领域要有足够的视野,一定要知道这个领域的工程界、学术界是什么情况,这样对自己在结合目的、目标以及一些约束条件下做出更合理的技术选型是非常重要的,之前也写过一篇关于如何扩充技术视野的文章。

  异地多活在核心问题上要解决的是请求封闭、数据一致性这两个关键问题,在为了解决这两个问题的设计上,参考了工程界的一些情况,最后发现我们所面临的状况还是很不一样。

  所以架构师我觉得绝对不是烂大街的头衔,要做到一个合格的架构师还是相当难的,尤其是工程类型的架构师,需要长期的实战、经验积累。

  系统设计一直是我认为最难讲的内容,主要还是因为我在内部尝试做的一个系统设计的培训,非常感谢一帮同学支持了我做这个培训,要不是他们的参与,我觉得不可能写这篇文章,也不可能较为体系化的说说系统设计,并且更重要的是让我觉得系统设计这个东西其实还是可以不讲的那么虚的,以及系统设计的技能一定程度上确实也是可以培养的。

  阿里妹导读:18年前,200家企业由于在事故中信息系统遭到严重破坏而永远地关闭了。这样的事故引发了后人深思,对于工程师而言,不仅要求设计的系统足够强壮,还需要具备考虑失败的能力,当失败场景悉数被考虑周全、并且结合充分的演练,一切会不会不一样?我们熟知面向对象设计和面向程序设计,阿里巴巴资深技术专家游骥洞悉行业现状,抛出了一个新模式——面向失败设计。今天,听他娓娓道来,如何在一开始的系统设计阶段就考虑到各种失败场景,把面向失败当成是系统设计的一部分,准备好从失败中恢复的策略。

  一个优秀的架构师通常都是一个悲观主义者,除了设计好能够支撑业务持续发展的优雅架构,另一个容易被忽略的重要能力在于充分考虑失败场景。如果对失败场景考虑不够充分,轻则出现业务不可用,影响用户体验和企业声誉;重则导致数据永久丢失、业务再无恢复可能。

  2001 年 9 月 11 日,美国世贸中心双子大厦遭受了谁也无法预料的恐怖打击,灾难发生前约有 350 家企业在世贸大厦中工作,事故发生一年后,重返世贸大厦的企业变成了 150 家,有200 家企业由于重要信息系统的破坏,关键数据的丢失而永远关闭、消失了,其中的一家公司声称自己要恢复到灾难前的状态需要 50 年的时间。

  “Everything fails, all the time”,无论是在传统软件时代还是在互联网、云时代,系统终究会在某个时间点失败,面向失败的设计理念数十年来并没有多大的变化,不同的是在分布式、云架构的互联网时代:失败将由小概率偶发事件变成常态,同时应对和处理失败的具体实现方式也大相径庭。

  单个技术点在绝大部分时间都能按照设想正常工作,但是当规模和复杂度到达一定程度,失败其实无所不在。当你的业务场景从服务企业内部的几百号员工变成面向上亿的外部用户,你不确定你的用户群会有些什么样的角色,也不知道他们会在你的系统平台上创造出什么样的业务行为;当你的技术框架从单机、一体机演进到分布式的多层、多组件架构,原本5个以内的技术组件可能变成了今天的500个,并且为了用较低的成本保持服务能力的扩展能力,你可能放弃了稳定性更好但也昂贵的商业技术、转而用开源自建来替代。

  互联网业务快速发展不仅直接带来了流量、安全等不确定性,同时促使了技术架构的快速演进,使架构变得越来越复杂,这些因素都将导致失败发生的概率大幅提升。当人类的工作、生活越来越依赖互联网,一旦出现失败,造成的影响和损失将是空前巨大的。在远古时代,人类没有自来水也没有电,一切都很好;今天如果停电停水一段时间,相信很多人都会无法适应,而互联网正在逐步演变成跟水和电一样的基础设施。失败的原因多种多样,抽象来看可以分为以下几类:

  首先,硬件是有生命周期的,它一定会老化,并且你不知道它会在什么时候坏;其次,硬件是一个实体,它存在于客观环境当中,它的状态会受外部环境干扰,比如火灾、地震等外力因素都可能导致硬件损坏;最后,所有硬件都会存在残次品,你很可能就是那个不幸者。通常情况下单个硬件出问题的概率不高,但是当有几十万的硬件设备,硬件的失败问题每天都会发生。

  系统运行态的日常运维过程当中,难免会因为疏忽或者考虑不周全导致灾难。当上万名技术同学跟上百个变更系统做笛卡尔积,哪怕是6个9的可靠性,依旧无法做到万无一失。全局的流量入口、权限与安全验证体系、统一网关与接口平台等技术环节是可能促发全站不可用的重要风险点,对于影响面大的配置的变更需要尤为谨慎。

  原本工作得很好的程序随着时间的推移可能有一天不再正常工作,举几个常见的例子:自增变量运行了很长一段时间后出现越界、缓存随着数据量的逐渐变大而出现空间不足、数据库连接池随着机器的扩容而不够用等等。千万不要认为运行良好的系统是不会出问题的,它的代码里面可能藏了定时炸弹,只是你不知道会在什么时间点爆炸。

  作为一个悲观主义者,你需要在一开始的系统设计阶段就考虑到以上各种失败场景,把面向失败当成系统设计的一部分,并且准备好从失败中恢复的策略,这有助于更好地提升整个系统的可用性。只有你意识到事情会随着时间的推移而失败,并将这种思想融入到体系结构中,那么在失败发生的时候你才能完全不受影响或者将失败损失降到最低。面向失败的设计理念数十年来并没有多大的变化,一些好的经典原则在今天依旧被广泛运用。

  除了局部失败场景,你的系统可能还面临着大范围的失败场景。大范围的原因有两个:天灾,比如火灾、地震、台风、雷电等大的自然灾害可能导致大面积的基础设备被毁坏;人祸:人的失误或者刻意破坏行为有时候也会酿成大祸,如操作错误、破坏、植入有害代码和。“面向失败的宏观多活架构”从宏观架构的高可用层面来解决系统的整体可用性问题,随着技术的演进,冷备、热备、两地三中心、异地多活等应对大范围失败场景的技术体系这些年频频被提起。

  如何来衡量一个软件系统的设计是否优良?一条很重要的衡量标准——在任何情况之下你的软件系统都应该工作在当前环境的最优状态。每个人都知道机翼是飞机的重要部件,一旦机翼出现问题,飞机很可能就会坠落。然而在二战当中,许多战斗机即便机翼千疮百孔了,依然保持着最佳战斗能力;甚至还有更夸张的情况:1983年的一次战斗机演习当中,一架飞机由于事故损失了一个机翼,这架缺少一个机翼的飞机依然保持了飞行能力、最终完成安全着陆。

  软件系统由两部分构成:系统自身的代码和依赖的库以及服务。“服务能力与依赖调用自我保护”需要从这两块分别切入构建系统在任意情况都始终工作在最佳状态的能力。服务限流、系统负载保护、给依赖的服务设置超时或者资源限制等都是相应的应对策略。

  能够抵抗失败和从失败中快速恢复是面向失败设计的核心思想,然而即便已经做了万全的设计,也并非所有的失败场景都是系统能够自动抵御的。你需要考虑到所有的失败场景,并准备好相应的应对预案。为一切不可预料的情况备好预案才能在失败场景真正发生时做到有条不紊。做好预案需要对失败场景有全面的考虑:会发生哪些失败?失败会带来什么问题?应对策略是什么?预期的恢复时间多久?恢复后的影响面有多大?需要通知到哪些角色?等这一系列的因子构成了一个完整的预案体系。

  大量的系统故障是因为人的失误造成的,即便让一个优秀的运维工程师进行一万次同样的运维操作也难免不出错。唯一的解决办法便是在运维过程当中尽可能降低人为操作的比重。系统化、白屏化是第一个阶段——将人为的操作步骤固化成系统程序,避免操作失误;自动化以及智能化是第二个阶段——将正确的决策过程也固化成智能程序,避免决策失误。同时所有的运维动作都需要遵循灰度原则,做到可灰度、可监测、可回滚,即便出现了失误也能控制好爆炸半径,并且做到快速恢复。

  面向失败设计不仅要求你的系统足够健壮,同时要求你能够在第一时间感知到失败的发生。无论是自动化的系统恢复,还是人为介入,如果你压根都不知道是哪里出问题了,一切都将束手无策。精细化的监控体系一方面能够在出现问题的时候以最快的速度将最准确的信息传递到人或者运维系统,同时它还能够展现趋势、进行提前预警。AI技术的结合使得监控领域在近几年得到了新的发展驱动力:智能监控报警、根因定位、智能预测、智能决策等能力都是学术界和工程界非常热衷的课题。

  最后,即便以上工作都做好了,你也不能高枕无忧去等待失败到来。你的设计、系统、流程、技术人员等需要通过不断演练,来保障能力和进化升级。对于代价非常巨大的事件,做好前期的充分演练是非常有必要的,比如军事演练、消防演练等都属于这一范畴。而系统不可用的代价对于企业来讲很可能是无法承受的,因此需要在平时做好充分的演练:通过故障与攻防演练锤炼容灾应急能力,对面向失败的设计做好充分验证。只有当所有的失败场景都被提前演练过,当失败真正来临时才能做到胸有成竹。

Power by DedeCms