精华内容
下载资源
问答
  • 解决方案架构师
    千次阅读
    2021-03-02 11:28:01
    摘要:且听有着15年软件研发、架构经验的华为云MVP魏群娓娓道来,如何成为一名合格的解决方案架构师?

    架构师,这是一个在技术人员,特别是软件开发人员眼中具有神圣色彩的岗位。

    团队中有了架构师,就是有了技术脊梁,有了技术保障。众多程序员们也憧憬自己成为架构师,可以把控全局、统筹设计,做出具有自己独特印记的系统。

    那么,什么是解决方案架构师?需要哪些能力素质,我们才可以成为一名合格的解决方案架构师?

    且听有着15年软件研发、架构经验的华为云MVP魏群娓娓道来。

    初识架构师

    每谈到架构师话题,魏群都很有感触。

    “2004年刚参加工作不久,当时的团队有一位架构师,主要负责整体设计以及编写一些基础代码。出于对大牛的好奇,我经常会刻意去看他的代码,说实话那时候常常很迷糊,明明可以很简单解决的问题,他却用了很多看似没什么用的分层、封装和接口化设计。”

    后来,随着项目经验的增加和编程技能的提升,魏群才知道这就是所谓软件架构,看似繁琐的代码,本质是为了解决软件系统的复杂度的问题,以更好的支持开发人员编写更为健壮的业务代码,更灵活的响应个性化需求,最终给产品提供了更好的质量与扩展弹性。

    和这位架构师一起工作的经历,也直接影响了魏群以后的技术追求和发展规划。

    在魏群看来,架构的核心是规划、设计和识别。而架构师,就是负责从这三个核心角度来解决特定领域问题的专项工作角色。

    对于IT技术行业而言,可将架构师简单分为四类:

    • 特定技术架构师(Technology-Specific Architect,TSA):关注特定开发语言、软件系统、网络安全、数据等专项技术;
    • 基础结构架构师(Infrastructure Architect,IA):提炼优化技术方面的积累沉淀;
    • 解决方案架构师(Solution Architect,SA):关注特定目标和需求的解决方案;
    • 企业架构师(Enterprise Architect,EA):关注企业技术路线和技术发展方向。

    这个分类顺序,恰恰也是架构师的进阶之路,即从一个相对专注的专项架构师到更抽象、全面、具有企业顶层设计能力的企业架构师。

    在这个过程中,解决方案架构师是重要的节点,其所需具备的能力和技术更为综合化,面对的业务和环境更为复杂,也是走向企业级架构师的必由之路。

    架构师成长之路(引自网络)

    以下将从解决方案架构师应具备的素质能力以及如何成为一各合格的解决方案架构师两个方面来阐述,给有志于成长为解决方案架构师的同学参考。

    从实际案例看,解决方案架构师要有哪些能力?

    一般来说,解决方案就是把各种产品、技术或理论方法,不断地进行优化组合及创新,从而满足用户的特定目标和需求。

    解决方案架构师则要从繁杂纷乱的业务需求和问题现象中抽丝剥茧,提炼和设计解决方案,从而帮助客户把想法、问题、需求落地成一个可以执行、可实施的项目。

    同时,解决方案架构师还要具有跨领域的能力,即拥有横向和纵向两种能力。

    纵向是在某一领域的沉淀深度,横向则是跨业务领域的知识广度。解决方案架构师经常会在方案设计过程中碰到多种领域的综合分析和设计的场景,这也是其最主要的挑战来源。不过反过来讲,边界清晰、逻辑简单的业务,可能也无需架构师参与了。

    从能力模型上看,解决方案架构师要以个人内在素质为核心(其实这也是所有工作岗位的核心),同时具备业务能力、技术能力和人际关系能力的综合化能力体系。

    解决方案架构能力模型(引自网络)

    魏群分享了一个案例:为了更好的应对疫情,支持医务人员线上学习,他们公司需要快速研发一款远程医学教育平台。

    项目涉及到视频直播相关技术选型,经过初步调研后发现华为云提供的视频直播、互动直播、视频会议、实时音视频等各种视频服务解决方案,似乎都可以支持远程医教项目中的直播需求,开发组有些无从下手。

    此时,就需要架构师对这些看似都可以使用的产品服务进行充分、多维度的跨技术、跨业务、跨场景了解和研究,找到最其优解的正确选型,从而构建最合适的解决方案。

    在此情况下,项目组的软件架构师梳理出3个需求关键点:

    1. 多方教师参与直播授课,且可实时音视频互动;
    2. 观看学员人数不限;
    3. 学员可视讯直播交互。

    根据梳理结果发现,直播技术方案需要满足:

    1. 具备实时音视频的能力(软件能力);
    2. 能根据观看直播人数动态调整网络对直播的支撑(网络能力);
    3. 无需专业视频设备的支持(硬件能力);

    基于以上,以及华为云协助下进行多维分析后,魏群他们最终选择互动直播方案来实现平台视讯能力,最终完美的实现了预期目标,获得用户好评。

    这正是基于跨技术、跨业务、跨场景的多领域融合分析并提供解决方案的能力体现。

    怎样成为一名解决方案架构师?

    在魏群看来,要成为一名合格的解决方案架构师,更需要在心态、能力、方法三个素养维度上加强锻炼和积累。

    一是心态上,要具有永不言败的挑战心态、分秒必争的学习心态、虚怀若谷的开放心态。作为最专业的咨询服务人员,要随时能够应对各行业、各领域的需求和各种风格的客户。在你坐到客户对面以前,你永远不知道他会给你抛出什么样的问题和挑战,所以面对未知的勇气和自信是重要的。其次是快速的学习能力,从未知到概念,从概念到理论,从理论到实践,从实践到经验,这是一个变未知为已知的必然过程。

    另外就是要以尊重、敬畏和开放的心态面对每一个行业,每一个领域以及每一个业务参与人员,避免盲人摸象和眼高手低,这样才能保证自己处于一个正确的立场和角度去看待问题,抓住重点的同时关注到每一个细节,进而找到最为合适的思路。

    二是技能上,要具有高度的抽象能力、高效的沟通能力、专精的业务能力、广泛的技术能力、接地的实施能力。

    解决方案架构师未必对每一项技术都精通或达到多少深度,但他必须具有一定的广度知识,且能够掌握常用的、领先的逻辑技术实现方式,以技术需求的方式描述出来。

    另外就是实施能力,解决方案架构师并非纸上谈兵,而是要能够将自己所构建的方案,落地实施转化为成效。

    三是方法上,要具有战略思考的方法、设计思维的方法。解决方案架构师要具备有效的工作方法来进行能力转化输出。

    其中,战略思考是架构师与普通技术人员最大的区别,包括基于敏锐的洞察力揭示现象、触及本质,进而联想构建,从顶层化、系统化思考方案,以最大限度的解决根本问题。

    而设计思维则是要通过一定的步骤(同理心、定义问题、创意、原型、测试和重复迭代输出),与用户体验同一视角,微观中构架方案,聚焦提出有意义的创意和想法,来解决特定人群的实际问题。

    结语

    以上就是魏群对于解决方案架构师的相关学习理解和思考。

    最后再引用一句话:一个好的解决方案架构师一定是出去能够讲故事,回来能够写方案,然后还可以带项目做实施的“全才”,这三个环节缺一不可。

    成为这个“全才”,虽有方法但无捷径,需要端正的心态和取长补短的学习,再加上不断的实践、总结和沉淀,方可成为一名合格的,名符其实的解决方案架构师。

    部分内容参考自:

    什么是架构师?

    https://zhuanlan.zhihu.com/p/38780884

    凯哥讲故事[001]解决方案架构师能力模型

    https://www.jianshu.com/p/bd9962ba3c22

    做人做事、做架构师,架构师能力模型解析

    http://blog.sina.com.cn/s/blog_757658ba0100r19k.html

     

    本文分享自华为云社区《【云上苏城,以梦为码】华为云MVP魏群:如何成为一名优秀的解决方案架构师》,原文作者:我们都是云专家 。

     

    点击关注,第一时间了解华为云新鲜技术~

    更多相关内容
  • 高级架构师.zip,高级架构师,题目.docx,天翼云高级解决方案工程师认证重点知识点V2(1).pdf,解决方案高级考试大纲.docx
  • AWS(亚马逊)云解决方案架构师面试实践过程作业(Assignment#2)即第3轮面试全英PPT演示文档,可以帮您少走很多弯路
  • 1面实践题,完成:created a web site using the following Amazon Web Services: EC2, EBS, ELB, EIP and S3
  • AWS(亚马逊)云解决方案架构师面试实践过程作业(Assignment#2),可以帮您少走很多弯路
  • 认证解决方案架构师助理学习指南(EN)
  • 华为 HCIP-Cloud Service Solutions Architect V1.0 云服务解决方案架构师 官方认证教材.rar,华为 HCIP-Cloud Service Solutions Architect V1.0 云服务解决方案架构师 官方认证教材,HCIP-Cloud Service Solutions ...
  • AWS 认证解决方案架构师官方学习指南
  • BRIEF Imagine that you meet with a small startup company in the early stages of their operations....PC within their small office. Like many small start-ups they are confident that they will be the next ...
  • AWS官方推出的解决方案架构师(AWS Certified Solutions Architect)认证培训课程,本文档为官方Lab实验指南。通过本指南可以详细了解到如何通过AWS控制台在云平台上部署适用的Web站点以及实现相关的高可用性,可结合...
  • 解决方案架构师的职责

    千次阅读 2021-06-04 17:08:34
    了解解决方案架构师的职责 1.分析用户需求 2.定义非功能性需求 3.参与并与利益相关者合作 4.处理各种架构约束 5.进行技术选择 6.开发概念证明和原型 7.设计解决方案并坚持交付 8.确保发射后的可操作性和维护 9.作为...

    了解解决方案架构师的职责
    1.分析用户需求
    2.定义非功能性需求
    3.参与并与利益相关者合作
    4.处理各种架构约束
    5.进行技术选择
    6.开发概念证明和原型
    7.设计解决方案并坚持交付
    8.确保发射后的可操作性和维护
    9.作为技术传播者工作

    1.分析用户需求
    业务需求是任何解决方案设计的核心,它们在项目开始时以原始术语定义。从一开始就有必要让不同的团队参与进来,其中包括识别需求的技术能力。业务利益相关者定义需求,并且在技术演进方面需要进行多次调整。为了省力,有必要在定义用户需求文档时聘请解决方案架构师。

    解决方案架构师设计应用程序,这可能会影响整体业务成果。这使得需求分析成为解决方案架构师应该具备的一项关键技能。一个好的解决方案架构师需要具备业务分析师的技能以及与不同的利益相关者合作的能力。

    解决方案架构师为他们带来了广泛的业务经验。他们不仅是技术专家,而且对业务领域有很好的了解。他们与产品经理和其他业务利益相关者密切合作,以了解需求的所有方面。一个好的解决方案架构师可以帮助产品团队发现隐藏的需求,非技术利益相关者从整体解决方案的角度可能没有考虑过。

    2.定义非功能性需求
    用户和客户可能无法直接看到非功能性需求(NFR),但它们的缺失可能会对整体用户体验产生负面影响并阻碍业务发展。NFR 包括系统的关键方面,例如性能、延迟、可扩展性、高可用性和灾难恢复。最常见的非功能性需求如下图所示:

    在这里插入图片描述

    解决方案设计中的 NFR
    上图显示了以下 NFR 供考虑:

    性能:
    用户的应用程序加载时间是多少?
    我们如何处理网络延迟?
    安全性和合规性:
    我们如何保护应用程序免受未经授权的访问?
    我们如何保护应用程序免受恶意攻击?
    我们如何满足当地法律和审计要求?
    可恢复性:
    我们如何从中断中恢复应用程序?
    发生中断时,我们如何最大限度地缩短恢复时间?
    我们如何恢复丢失的数据?
    可维护性:
    我们如何确保应用程序监控和警报?
    我们如何确保应用程序支持?
    可靠性:
    我们如何确保应用程序始终如一地执行?
    我们如何检查和纠正故障?
    可用性:
    如何保证应用的高可用?
    我们如何使应用程序具有容错性?
    可扩展性:
    如何满足日益增长的资源需求?
    我们如何才能在利用率突然飙升的情况下实现良好的规模?
    可用性:
    我们如何简化应用程序的使用?
    我们如何才能实现无缝的用户体验?
    但是,根据项目的性质,可能存在仅适用于该项目的 NFR(例如,呼叫中心解决方案的语音清晰度)。您将了解更多有关这些属性的第3章,属性的解决方案架构的。

    解决方案架构师从很早的阶段就开始参与项目,这意味着他们需要通过衡量组织中跨组的需求来设计解决方案。解决方案架构师需要确保跨系统组件和需求的解决方案设计的一致性。解决方案架构师负责定义跨组和不同组件的 NFR,因为他们确保全面实现解决方案所需的可用性。

    NFR 是解决方案设计的一个不可或缺的重要方面,当团队过于关注业务需求时,它往往会滑倒,这会影响用户体验。一个好的解决方案架构师的主要责任是传达 NFR 的重要性并确保它们作为解决方案交付的一部分得到实施。

    3.参与并与利益相关者合作
    利益相关者可以是对项目有直接或间接利益的任何人。除了客户和用户之外,还可能是开发团队、销售、营销、基础设施、网络、支持团队或项目资助组。

    利益相关者可以是项目内部的或外部的。内部利益相关者包括项目团队、发起人、员工和高级管理层。外部利益相关者包括客户、供应商、供应商、合作伙伴、股东、审计师和政府。

    通常,利益相关者根据他们的上下文对同一业务问题有不同的理解;例如,开发人员可能会从编码的角度来看业务需求,而审计人员可能会从合规性和安全性的角度来看它。解决方案架构师需要与所有技术和非技术利益相关者合作。

    他们拥有出色的沟通技巧和谈判技巧,有助于找出解决方案的最佳途径,同时让每个人都参与其中。解决方案架构师作为技术和非技术资源之间的联络人,填补了沟通空白。通常,业务人员和技术团队之间的那些沟通差距会成为失败的原因。业务人员试图更多地从特性和功能的角度来看待事物,而开发团队则努力构建一个技术上更兼容的解决方案,有时可能会倾向于项目的非功能方面。

    解决方案架构师需要确保两个团队在同一页面上,并且建议的功能在技术上也是兼容的。他们根据需要对技术团队进行指导和指导,并将他们的观点转化为每个人都能理解的简单语言。

    处理各种架构约束
    架构约束是解决方案设计中最具挑战性的属性之一。解决方案架构师需要仔细管理架构约束,并能够在它们之间进行协商以找到最佳解决方案。通常,这些限制相互依赖,强调一个限制可能会夸大其他限制。

    最常见的制约因素如下:听

    ##解决方案设计中的架构约束
    在这里插入图片描述

    如上图所示,解决方案设计帮助我们了解应用程序的以下属性:

    费用:
    有多少资金可用于解决方案实施?
    预期投资回报( ROI )?
    质量:
    结果应该与功能性和非功能性需求的匹配程度如何?
    我们如何确保和跟踪解决方案的质量?
    时间:
    什么时候应该交付输出?
    时间上有弹性吗?
    范围:
    确切的期望是什么?
    需求差距需要如何处理和容纳?
    技术:
    可以利用什么技术?
    使用传统技术与新技术相比,使用哪些灵活性?
    我们应该内部构建还是从供应商处采购?
    风险:
    会出现什么问题,我们如何减轻这种情况?
    利益相关者的风险承受能力如何?
    资源:
    完成解决方案交付需要什么?
    谁将负责解决方案的实施?
    合规性:
    哪些当地法律要求会影响解决方案?
    审核和认证要求是什么?
    可能存在与项目相关的更具体的限制,例如由于政府监管而将数据存储在某个国家/地区,以及出于安全考虑选择内部开发。处理约束可能非常棘手。通过减少资源来节省成本可能会影响交付时间表。

    在资源有限的情况下实现计划可能会影响质量,这反过来又会因不需要的错误修复而增加成本。因此,在成本、质量、时间和范围之间找到平衡非常重要。范围蔓延是最具挑战性的情况之一,因为它会对所有其他约束产生负面影响,并增加解决方案交付的风险。

    解决方案架构师必须了解每个约束的所有方面并能够识别任何由此产生的风险。他们必须制定风险缓解计划并在它们之间找到平衡。处理任何范围蔓延对按时交付项目有很大帮助。

    5.进行技术选择
    技术选择是解决方案架构师角色的关键方面和复杂性。可用的技术范围很广,解决方案架构师需要为解决方案确定正确的技术。解决方案架构师需要拥有广泛和深入的技术才能做出正确的决策,因为所选的技术堆栈会影响产品的整体交付。

    每个问题都可以有多种解决方案和可用的技术范围。为了做出正确的选择,解决方案架构师需要牢记功能需求和 NFR,并在制定技术决策时定义选择标准。选择的技术需要考虑不同的角度,无论目标是与其他框架和 API 集成的能力,还是满足性能要求和安全需求。

    解决方案架构师应该能够选择不仅满足当前需求而且可以扩展以满足未来需求的技术。

    6.开发概念证明和原型
    创建原型可能是解决方案架构师最有趣的部分。要选择一种经过验证的技术,解决方案架构师需要在各种技术堆栈中开发概念证明( POC ),以分析它们是否适合解决方案的功能和非功能需求。

    开发 POC 的想法是用关键功能实现的子集来评估技术,这可以帮助我们根据其能力决定技术堆栈。它的生命周期很短,仅限于由团队或组织内的专家审查。解决方案设计 POC 是解决方案架构师试图找出解决方案的构建块的时候。

    在使用 POC 评估多个平台后,解决方案架构师可以继续对技术堆栈进行原型设计。开发原型用于演示目的并提供给客户,以便它可以用于确保资金。POC 和原型设计绝不是生产就绪的;解决方案架构师构建的功能有限,这可能是解决方案开发的一个具有挑战性的方面。

    7.设计解决方案并坚持交付
    解决方案架构师在了解功能需求、NFR、解决方案约束和技术选择的不同方面后开始解决方案设计。在敏捷环境中,这是一种迭代方法,其中需求可能会随时间变化并需要适应解决方案设计。

    解决方案架构师需要设计一个面向未来的解决方案,该解决方案应该具有强大的构建块并且足够灵活以适应变化。但是,解决方案架构师需要注意需求的急剧变化并应用风险缓解计划。

    对于面向未来的设计,您可以以基于 RESTful API 的松散耦合微服务架构为例。这些架构可以扩展到新的需求,并且能够轻松集成。您将了解不同的体系结构设计,在第6章,听解决方案架构设计模式。

    以下流程图显示了解决方案交付生命周期。解决方案架构师参与解决方案设计和交付的所有阶段:

    解决方案交付生命周期
    在这里插入图片描述

    如上图所示,解决方案交付生命周期包括以下内容:

    业务需求和愿景:解决方案架构师与业务利益相关者合作以了解他们的愿景。
    需求分析和技术愿景:解决方案架构师分析需求并定义技术愿景以执行业务战略。
    原型设计和推荐:解决方案架构师通过开发 POC 和展示原型来进行技术选择。
    解决方案设计:解决方案架构师根据组织的标准并与其他受影响的团体合作开发解决方案设计。
    开发:解决方案架构师与开发团队合作进行解决方案开发,并充当业务团队和技术团队之间的桥梁。
    集成和测试:解决方案架构师确保最终解决方案按预期工作,满足所有功能和非功能需求。
    实施:解决方案架构师与开发和部署团队合作以顺利实施并指导他们克服任何障碍。
    运维:解决方案架构师确保日志记录和监控到位,并根据需要指导团队进行扩展和灾难恢复。
    但是,整个生命周期是一个迭代过程。一旦应用程序投入生产并且客户开始使用它,您可能会从客户反馈中发现更多需求,这将推动未来增强的产品愿景。

    解决方案架构师在解决方案设计期间拥有主要所有权,他们在其中执行以下操作:

    记录解决方案标准
    定义高级设计
    定义跨系统集成
    定义不同的解决方案阶段
    定义实施方法
    定义监控和警报方法
    记录设计选择的优缺点
    记录审计和合规要求
    解决方案架构师不仅负责解决方案设计。他们还帮助项目经理进行资源和成本估算、定义项目的时间表和里程碑、项目的发布及其支持计划。解决方案架构师在解决方案生命周期的不同阶段工作,从设计到交付和发布。解决方案架构师通过提供专业知识和广泛的理解帮助开发团队克服障碍和障碍。

    8.确保发射后的可操作性和维护
    解决方案架构师在解决方案上线后,在产品的可操作性上扮演着不可或缺的角色。为了处理不断增长的用户群和产品利用率,解决方案架构师应该知道如何扩展产品以满足需求并确保高可用性而不影响用户体验。

    在不可预见的事件(例如中断)中,解决方案架构会指导您执行灾难恢复计划以继续业务流程。将溶液建筑师满足组织ř ecovery点目标听(RPO)和- [R ecovery点目标听(RTO)。RPO 是组织在中断间隔期间丢失的数据量(例如,15 分钟的数据丢失)方面可以容忍的数据丢失量。RTO 是系统恢复并再次运行所需的时间。您将了解RTO和RPO在第12章,听的DevOps和解决方案体系结构框架。

    如果由于需求增加而出现性能问题,解决方案架构师可以帮助横向扩展系统以缓解应用程序瓶颈或纵向扩展以缓解数据库瓶颈。您将了解不同的缩放机制和自我修复在第9章,建筑可靠性因素。

    解决方案架构师计划适应现有产品中因使用模式或任何其他原因而产生的任何新需求。他们可以根据监控用户行为对非功能性需求进行更改;例如,如果加载时间超过 3 秒,用户就会跳出页面。解决方案架构师通过这个工作并指导团队处理发布后可能发生的问题。

    9.作为技术传播者工作
    布道者是解决方案架构师角色中最令人兴奋的部分,他们作为技术布道者工作。解决方案架构师通过公共论坛传播信息来提高产品和平台的采用率。他们撰写有关解决方案实施的博客并举办研讨会以展示潜在的好处和技术平台的使用。

    他们建立对技术的大规模支持并帮助建立标准。解决方案架构师应该对技术充满热情。他们应该是一名优秀的公众演讲者,并拥有出色的写作技巧来扮演技术传播者的角色。

    展开全文
  • 我眼中的解决方案架构师

    千次阅读 2020-11-16 10:00:00
    凌云时刻 · 故事导读:一位阿里云解决方案架构师的自述。作者|陈兵来源 | 凌云时刻(微信号:linuxpk)何为架构师我是在 2018 年加入阿里云,最开始是做一名软件开发工程师...

     

    凌云时刻 · 故事

    导读:一位阿里云解决方案架构师的自述。

    作者 | 陈兵

    来源 | 凌云时刻(微信号:linuxpk)

    何为架构师

    我是在 2018 年加入阿里云,最开始是做一名软件开发工程师。那个时候,我经常和晓龙聚在一起探讨键盘的排列组合、语言的孰优孰劣、各种格子衫的穿法。当有一天龙哥发现我的 Title(岗位头衔)变成了架构师之后,对我的态度骤然冷淡起来,每次我满怀热情地去和他讨论问题,他总是对我却爱理不理。终于有一天我忍不住去拉住从对面走来却假装望天的龙哥这是为什么?原来龙哥觉得我键盘敲得没有他响,快捷键记得没有他全,竟然连 emacs 都不喜欢,只是因为“脱口秀”说得好就成为了架构师,简直太没有天理了。

    架构师这个岗位在软件工程师来看是一个很神圣的岗位,也是众多开发人员努力的目标,大家都在幻想有一天全局由自己来把控,整体由自己来设计,做出好作品的召唤是每个开发人员的动力。但就像好作品可以分为许多种类一样,架构师同样也可以分为很多种类。

    例如 Gartner 对架构师的分类会从商业、信息和技术(Business, Information and Technical)等维度出发,涉及到的角色是我们常见的,如企业架构师(Enterprise Architect)、解决方案架构师(Solution Architect)。同样也有按照功能分类来定义架构师的角色,从技术角度来看涉及到我们常见熟知的岗位:系统架构师(System Architect)、软件架构师(Software Architect)、数据架构师(Data Architect)、安全架构师(Security Architect)、交付架构师(Delivery Architect)等等。

    面对不同客户的真实需求中,其实架构师之间是可以协同合作的,在不同阶段发挥着不同的作用。

    《水浒传》中智取生辰纲的桥段很好地展示了不同架构师角色在一个项目中的作用:杨志烈日下带队押送生辰纲经过太行山黄泥岗被晁盖、吴用等人用蒙汉药酒懵倒,晁盖等七人毫发无损地完成了劫走生辰纲不可能的任务。桥段最后的描写“这七人端的是谁?不是别人,原来正是晁盖、吴用、公孙胜、刘唐、三阮等七个人。却才那个挑酒的汉子,便是白日鼠白胜。却怎地用药?原来挑上冈子时,两桶都是好酒。七个人先吃了一桶,刘唐揭起桶盖,又兜了半瓢吃,故意要他们看着,只是叫人死心搭地。次后吴用去松林里取出药来,抖在瓢里,只做赶来饶他酒吃,把瓢去兜时,药已搅在酒里,假意兜半瓢吃,那白胜劈手夺来,倾在桶里,这个便是计策。那计较都是吴用主张,这个唤作“智取生辰纲”。

    这段描写清楚地描述了整个“项目中”的角色,系统(企业)架构师晁盖,公孙胜完成了整个组织团队的搭建后,解决方案架构师吴用设计了整套计策(方案),由交付架构师白胜,刘唐等将这个方案进行完美实施达到了目标。

    所以,龙哥作为一名合格资深的开发人员,他想要成为的架构师其实是技术架构师分类中的软件架构师,而我的架构师 title 其实是解决方案架构师,两者在职责分配和日常工作重点上都有比较大的区分,相信龙哥看过这篇文章之后又可以同我一起愉快地讨论格子衫的穿法了。

    随着云计算的概念越来越普遍被接受,解决方案架构师(Solution Architect)或者细分的云计算解决方案架构师(Cloud Architect)越来越多地出现在大家的视野中,那到底何为解决方案架构师?为什么会有这类岗位的出现?具体职责是什么?如何在真正项目中起到作用的?接下来的讨论都是据此展开。

    何为解决方案架构师

    解决方案架构师(SA)的角色往往出现在为客户提供复杂的产品组合的公司当中,比如为客户提供各类服务器产品组合的 HP、Dell,为运营商提供从接入网到核心网组合的电信设备商 Ericsson、HUAWEI,到现在提供各类产品组合的云计算供应商阿里云、AWS 等等。这类公司的客户所面临的问题都不止一种解法,如何在折衷和协调之中选择出最优的答案或者最合适的答案,就是解决方案架构师(SA)的职责所在。

    解决方案架构师(SA)最常见的工作是输出各类设计方案,虽然客户的场景和行业各有不同,但面对千变万化的需求和场景下的方案依然可以遵循一定的规范。

    A solution fulfills a mission.
    方案当有明确的目标。

    解决方案架构师的出现是为了帮助客户达成一定的目标或者解决一定的问题,所以每个方案的设计都应该在基于明确需求下进行。过去常见的场景是我们有相应的产品或解决方案,然后将已经成型的产品及方案售卖给潜在的客户,但随着敏捷,弹性,云计算等越来越流行,很多时候解决方案架构师会同客户共同面对一个问题及场景,然后根据这个场景共创一类解决方案。

    在云计算的场景下共创类的方案优势被进一步放大,相较于过去 IT 提供商的单一维度,云计算服务商可以提供基于各类用户场景下组合方案,同时结合众多云计算生态可以将方案定制化变成一种常态模式。

    Architecting often involves making tradeoffs. 
    架构师应该站在不同的角度。

    面对一个复杂组织的客户不同的部门一定都会站在各自的角度同解决方案架构师(SA)来阐述自己的诉求,例如对于很多传统行业公司的组织架构抽象类似下图:

    Figure 1 组织抽象示意

    不同的业务部门会产生相应的需求,需求会首先由业务 IT 团队转化成相应的技术需求,然后技术需求会由相应 IT 团队或者供应商来承接,最后向基础 IT 团队申请相应的 IT 资源,最后这类资源会由基础 IT 资源通过资源池来进行提供。

    解决方案架构师面对此类客户不同团队提供的需求重点会有很大不同,面对客户的基础 IT 团队方案的侧重点是可快速部署,资源可清晰划分,有已用的运维方法。面对客户的业务IT团队提供的方案要用成熟的方案或者联合生态的方案直面需求,同时平衡费用、性能及使用习惯。

    通过上面的例子可以看出,解决方案架构师要具备理解客户组织,业务及系统构成,在平衡各方利益的前提下制定最适合客户方案的能力。

    Solution is an ongoing activity.
    方案是过程而非结果。

    最好的方案一定是持续优化出来而非一次性设计的结果。例如各种客户在做云计算改造的场景中往往会选择一种最小化的方式进行尝试,然后逐步在将自己的核心系统迁移上云。随着配套的组织结构适应了云上的各种变化之后往往会进行整套系统的云原生改造,进而开始基于数据的平台数据化及智能化,整个过程会涉及到各方面利益权衡取舍一定是渐进的方式。而在整个过程设计中的最重要产出物往往是各种架构图,为了适应未来演进的架构图和作画有异曲同工之妙,在特定的场景下要做好留白,给未来场景留下想象的空间。

    从上面抛砖引玉的几点可以看出,解决方案架构师(SA)对技术及业务广度的优先级要大于深度,对多项技能的综合掌握程度要求很高。在许多场景下对解决方案架构师(SA)最大的考验是判断能力,综合多方因素的情况下如何做出基于当前场景下做出最优解的判断是解决方案架构师最重要的职责。接下来我会选取一些真实客户合作的片段来展示解决方案架构师如何工作。

    以一个酒店娱乐行业的领军企业为例,在数字化转型的大背景下,这家企业正在积极使用各类新技术来帮助自身加速转型。但在实践过程中遇到了一些挑战,比如业务面临安全挑战风险非常大,安全引发的系统不稳定及引发后链路服务带来较差的客户体验;体验及安全问题对运维团队带来巨大挑战。

    在与企业负责人多次沟通相关解决方案和产品策略后,我们发现,这个客户面临的并非是单一的系统问题引发的技术挑战,而是一系列系统问题最终造成了对他客户的体验及满意度产生了问题。于是,我们达成合作,决定将整个项目的立项基于解决用户体验提升上而非单关注一的安全问题。

    整套系统的设计基于了阿里云上对 Anti-Bot、Anti-DDoS 等安全方案进行延展,使用了实人认证,风险识别等业务层手段解决了客户信任的问题,进而通过云安全中心和阿里云上 IT 治理的最佳实践帮助客户大幅减少运维操作中的人为及不可控因素。

    这个方案给客户带来了非常明显的业务价值:

    (1)基于阿里云上的 Anti-Bot、Anti-DDoS 等安全产品的应用解决了因为安全引发的系统稳定性问题。

    (2)通过实人认证及风险识别等业务安全方案帮助客户大幅减少针对业务欺诈行为。

    (3)通过移动推送,短信服务等服务增加了对其终端客户的体验提升。

    (4)基于编排工具及可追溯的操作审计大幅降低了客户云上运维的负责度及风险。

    Figure 2 架构图抽象示意

    解决方案架构师的价值

    在云计算被广泛接受的今天,整个市场对云计算及其相关行业的解决方案架构师(SA)提出了更多的要求,如何平衡左手边多达几百款可以提供的产品组合和右手边客户千变万化的需求是每个新时代解决方案架构师面对的问题。但同时技术和业务双重的需求也给了每个处在云计算时代架构师巨大的机会,各行各业对数字化转型人才的最重要部分都是对技术和业务双重的理解。所以新的时代背景下这个已经存在已久的岗位面临着新的定义和注解,而这份增添新色的机会和荣誉一定都属于置身赛场的解决方案架构师们。

    参考资料:

    《Systems and software engineering — Architecture description》

    《Gartner: Analyzing the Role and Skills of the Cloud Architect》

    《Beautiful Architecture》

    《阿里巴巴 Java 开发手册》

    《AWS_Well-Architected_Framework》

    《The Process of Software Architecting》

    END

    往期精彩文章回顾

    饿了么技术往事(中)

    饿了么技术往事(上)

    阿里云落地全球最大云原生实践:双11核心系统全面云原生化

    云上自动化部署和运维的正确姿势

    【cherry键盘白送】有人在云上送来一波双十一福利

    一位阿里云小哥要感谢“双11”,于是说了一段脱口秀……

    微服务框架 Go-Micro 集成 Nacos 实战之服务注册与发现

    如何做到数百万台车联网设备同时在线 0 故障

    2020CID|阿里云韩伟东:云原生底层系统思考

    如何将 KVM 异构虚拟机启动效率提升 6~10 倍?


    长按扫描二维码关注凌云时刻

    每日收获前沿技术与科技洞见

    展开全文
  • 9 1.5.2 公有云、私有云和混合云 10 1.5.3 公有云架构 10 1.5.4 公有云供应商和云服务产品 11 1.6 小结 12 第2章 组织中的解决方案架构师 14 2.1 解决方案架构师角色的类型 15 2.1.1 企业解决方案架构...

    2138e60c620a49dfe8d790612661d45e.gif技术领域的发展日新月异,IT专业人员为了自身的职业发展,必须与时俱进地掌握新技能。然而,在过去的十年中,这种快速变化的趋势已经在云计算领域中占据主导地位,成为“新常态”。现在,几乎每天都有云供应商发布新的公告、功能和服务更新,因此有必要建立持续学习的文化。与此同时,开发人员、数据库管理员、安全专业人员、构建/发布工程师等常规角色之间的典型界限逐渐变得模糊,这也导致了新角色的出现,这些角色需要着眼全局来把握端到端的完整流程。

    其中之一就是“解决方案架构师”,该角色从行业中现有的“应用架构师”和“IT架构师”等角色演变而来,现在已经成为主流。随着专业方向的不同,这个角色也发生了一些变化。最常见的是“云解决方案架构师”(Cloud Solutions Architect),该角色本身就相当动态。

    通常,IT专业人士希望能转换角色,但是他们缺乏在这条道路上取得成功的指导。

    988fdaa2170ea4bebe7cb6efe2400284.png

    《解决方案架构师修炼之道》正是围绕着从现有IT角色到解决方案架构师的有效转换展开,并以一种非常合理的方式说明了开启这段转换之旅的步骤。

    首先,本书简洁而贴切地说明了这个角色需要什么,以及它与其他类似角色有什么不同。

    之后,讲到了成为成功的解决方案架构师要具备的技术技能和各方面的知识。本书从基本的设计理念和架构原则(包括高可用性、可靠性、性能、安全性和成本优化)开始,对其中的每一方面进行深入探讨。

    本书还涵盖了有关云原生架构、DevOps以及数据工程和机器学习领域(现代架构的基石)的一些关键概念。

    强烈建议大家阅读这本书,并把它作为一份便利的参考资料一直留存,因为在书中你会发现非常重要的知识点,而这些知识将帮助你成为成功的解决方案架构师并开启一个充满无限可能的新世界!

    01

    目标读者


    本书适合从事IT行业的软件开发人员、系统工程师、DevOps工程师、架构师和团队负责人,以及有志于成为解决方案架构师并热衷于设计安全、可靠、高性能和高性价比的架构的人阅读。

    02

    本书涵盖内容

    • 第1章主要定义解决方案架构并解释其重要性。本章诠释了采用解决方案架构的各种益处,并探讨了在公有云上的架构设计。

    • 第2章讲述不同类型的解决方案架构师角色,以及他们如何融入组织结构。本章详细探讨了解决方案架构师的各种职责,并进一步说明了解决方案架构师在敏捷组织中的作用及如何与敏捷流程相适应。

    • 第3章揭示解决方案架构的各种属性,如可伸缩性、韧性、灾难恢复、可访问性、可用性、安全性和成本。本章解释了这些架构属性的共存和使用原则,以创建高效的解决方案设计。

    • 第4章讲述创建可伸缩、韧性和高性能架构的设计原则。本章通过应用安全性、克服约束、应用变更以及测试和自动化方法解释了什么是有效的架构设计,并通过探索面向服务的架构和采取数据驱动的方法来研究架构原则,从而有效地使用设计思维。

    • 第5章解释云的优势和设计云原生架构的方法。本章阐述了对于不同云迁移策略和迁移步骤的理解,讨论了混合云设计,并探讨了受欢迎的公有云供应商。

    • 第6章通过实例探讨各种架构设计模式,如分层、微服务、事件驱动、基于队列、无服务器、基于缓存和面向服务等模式。本章展示了解决方案架构属性和原则的适用性,以根据业务需求设计最佳架构,并解释了AWS云平台中的各种参考架构。

    • 第7章阐述应用程序性能提升的关键属性,如延迟、吞吐量和并发性。本章解释了在多个架构层级提高性能的各种技术选型,包括计算、存储、数据库和网络,以及性能监控。

    • 第8章讨论适用于保护工作负载安全的各种设计原则。安全性需要应用于架构的每一层和每一个组件,本章有助于了解正确的技术选型,以确保架构的每一层级都是安全的。本章探讨了适用于架构设计的行业合规性准则,并通过共享安全责任模型解释了云中的安全问题。

    • 第9章对促使架构可靠的设计原则进行讨论。本章探讨了各种用于确保应用程序的高可用性的灾难恢复技术,以及用于业务流程连续性的数据复制方法,解释了最佳实践和云在应用程序中实现可靠性的作用。

    • 第10章论述在应用程序中实现卓越运维的各种流程和方法。本章解释了适用于应用程序设计、实现和后期生产全流程的最佳实践和技术选型,以提高应用程序的可运维性,还探讨了云工作负载的卓越运维。

    • 第11章讨论在不影响业务敏捷性的情况下优化成本的各种技术。本章解释了用于监控成本和成本控制治理的多种方法,有助于读者理解云服务使用的成本优化。

    • 第12章解释DevOps在应用程序部署、测试和安全方面的重要性。本章探讨了DevSecOps及其在应用程序的持续部署和交付流程中的作用,讲述了DevOps的最佳实践以及实现这些实践的工具和技术。

    • 第13章讲述如何设计大数据和分析架构。本章概述了创建大数据流水线的步骤,包括数据摄取、存储、处理和可视化,帮助读者理解物联网所涉及的概念和技术,本章还探讨了有关机器学习、模型评估技术的详细信息,并对各种机器学习算法进行了概述。

    • 第14章讲述遗留系统的各种挑战和现代化驱动因素。本章解释了对遗留系统进行现代化改造的策略和技术。对许多组织来说,使用公有云正在成为首选策略,因此本章还探讨了遗留系统的云迁移。

    • 第15章讨论解决方案架构文档及其结构以及所需的各种细节。本章研究了各种IT采购文档(解决方案架构师需要参与其中以提供反馈)。

    • 第16章讲述胜任解决方案架构师所必需的各种软技能,有助于读者了解如何获得战略技能(如售前和高层沟通)、发展设计思维以及个人领导技能(如大局观和主人翁意识)。本章探讨了将自己打造成领导者并不断拓展自身技能的技巧。

    03

    大咖推荐

    本书是一本非常好的解决方案架构师手册,因为它系统、全面,并且与时俱进。这本手册涵盖了SOA、云迁移和混合云、无服务器、微服务、基于队列、事件驱动、大数据等架构设计模式,对性能、安全性、可靠性、运维、成本等进行了全方位考量,也涉及云原生架构、DevOps、数据工程和机器学习等一些崭新领域,从架构师的角色和职责开始,逐步深入探讨设计原则、设计模式及其实践。我相信,它会成为架构师的案头必备。

    ——朱少民,《架构之道:软件构建的设计方法》译者,

    《敏捷测试:以持续测试促进持续交付》作者,QECon大会发起人

    解决方案架构师对于软件产品开发而言越来越重要,只有根据业务场景做针对性的架构设计才能保证整体架构方案可落地。因此,解决方案架构师不仅是技术专家,更是千锤百炼的业务专家。成为一名优秀的解决方案架构师绝非一日之功,这本书好比一位向导,指引大家成为一名优秀的解决方案架构师。

    ——张尧,凯捷中国首席架构师

    如果说产品经理的价值是指导团队开发正确的产品,那么架构师的价值就是教团队以正确的方式开发产品。架构师其实有许多种,比如系统架构师、应用架构师、数据架构师、安全架构师等。如果说哪一种架构师既懂技术,又懂产品,还懂业务,那一定就是解决方案架构师。强烈推荐这本经典著作,阅读这本书会帮助你成为一名出色的综合型技术人才。 

    ——黄勇,《架构探险:从零开始写Java Web框架》作者

    在云服务成为数字化最重要的基础设施和驱动力的今天,围绕着云服务,以涵盖业务、应用、数据和基础设施的解决方案设计来指引数字变革,已越来越多地被各行业头部企业所采纳。而其中的架构设计,正是支撑这场变革的骨架。与之相适应,新的趋势、场景、技术也对投身其中的架构师提出了新的要求。本书很好地定位于这样的趋势当中,定位在云服务体系的数据和基础设施层面,从弹性、安全、灾备、DevOps、云迁移及混合云等若干重要维度展开,以架构设计的视角进行详细阐述。同时,结合这样的环境,对架构的含义、原则、模式和方法进行了再归纳和再升华。本书对于投身数字变革中的架构师来说是非常有益的给养。推荐大家阅读、参考。

    ——马徐,腾讯云高级战略专家,《服务设计方法与项目实践》译者

    解决方案架构师的重要性越来越受到行业的关注。这个角色由企业架构领域的应用架构师与IT架构师发展而来,它的兴起与演进,契合了当下从“架构适配业务的内部视角”到“业务驱动架构的外部视角”关注点变化的趋势。但是对于这个新兴的角色,行业中相关的文献仍显空白。很高兴看到这本书出版,它能为这个新角色的定义与发展提供指导。

    ——王健,Thoughtworks首席咨询师,“白话中台战略”系列文章作者

    解决方案如何解释?我的理解是:对一组抽象问题的一揽子解决办法。每个公司内部都面临着各种各样的业务问题,面对这些棘手的问题,解决方案架构可以帮助识别、理解、解决业务中出现的各类问题。在这个过程中,我们首先需要对解决方案架构的定义达成共识,并对解决方案架构的发展有深刻理解。强烈推荐几位好友联手翻译的这本书,它一定能帮到你。

    ——吴瑞诚,小米业务中台武汉负责人

    在第四次工业革命的浪潮之下,各行各业纷纷转战竞争激烈的数字化转型赛道。众人皆知转型之路需披荆斩棘,不仅需要绩效高、执行力强的研发团队,更需要一支着眼全局,从战略到战术视角定义问题和设计解决方案的架构团队。对于这样的架构团队,不同的企业皆有解读,然而林林总总的架构师头衔(解决方案架构师、云架构师、技术架构师、应用架构师等)往往会令从业者困惑不已。幸运的是,这本书的出版恰逢其时。它先从“道”出发,帮助读者理解这个时代下架构师面临的挑战以及架构设计原则。然后,进一步洞察了架构师的“法”和“术”,分享了云时代的架构设计模式、设计框架和方法。此外,本书也对优秀架构师的软技能和实战工具选择提出了期待。

    ——笪磊,Thoughtworks BeeArt产品负责人,

    《EDGE:价值驱动的数字化转型》《领域驱动设计精粹》译者

    在企业数字化转型过程中,一个重要的议题就是技术如何赋能业务,以及如何开创数字化业务。解决方案架构师在将业务目标和需求与数字化服务、产品及基础设施进行结合的过程中,担任了至关重要的角色。解决方案架构师是一位多面手,需要能透彻地理解业务,根据业务问题准确地提炼、抽象、设计解决方案,并最终使之落地。我的几位朋友翻译的这本书为有志于成为解决方案架构师的读者提供了系统性的指导。

    ——周柯,Thoughtworks中国区首席信息官

    解决方案架构师是未来IT架构中不可或缺的关键角色。本书作者从全球视角出发,经过多年沉淀积累,总结出一套科学、严谨的解决方案架构师参考指南。几位译者在翻译的过程中,亦融入了许多专业见解,对处于困惑之中的解决方案架构师起到了领航的作用。

    ——方强,旺米科技创始人

    04

    目录

    第1章 解决方案架构的含义  1

    1.1 什么是解决方案架构  2

    1.2 解决方案架构的演进  4

    1.3 解决方案架构为何如此重要  5

    1.4 解决方案架构的益处  5

    1.4.1 满足业务需求和交付质量  7

    1.4.2 选择最佳技术平台  7

    1.4.3 处理解决方案的约束和问题  7

    1.4.4 协助资源和成本管理  8

    1.4.5 管理解决方案交付和项目生命周期  8

    1.4.6 解决非功能性需求  8

    1.5 公有云中的解决方案架构  9

    1.5.1 什么是公有云  9

    1.5.2 公有云、私有云和混合云  10

    1.5.3 公有云架构  10

    1.5.4 公有云供应商和云服务产品  11

    1.6 小结  12

    第2章 组织中的解决方案架构师  14

    2.1 解决方案架构师角色的类型  15

    2.1.1 企业解决方案架构师  17

    2.1.2 解决方案架构师  17

    2.1.3 技术架构师  18

    2.1.4 云架构师  18

    2.1.5 架构师布道者  18

    2.1.6 基础设施架构师  19

    2.1.7 网络架构师  19

    2.1.8 数据架构师  20

    2.1.9 安全架构师  21

    2.1.10 DevOps架构师  21

    2.2 理解解决方案架构师的职责  22

    2.2.1 分析用户需求  22

    2.2.2 定义非功能性需求  23

    2.2.3 与利益相关者的接触与合作  25

    2.2.4 处理各种架构约束  25

    2.2.5 技术选型  27

    2.2.6 概念验证和原型开发  27

    2.2.7 设计解决方案并持续交付  28

    2.2.8 确保发布后的可操作性和可维护性  29

    2.2.9 担任技术布道者  30

    2.3 敏捷组织中的解决方案架构师  30

    2.3.1 为什么选择敏捷方法论  30

    2.3.2 敏捷宣言  31

    2.4 小结  35

    第3章 解决方案架构的属性  36

    3.1 可伸缩性和弹性  37

    3.1.1 容量伸缩困境  38

    3.1.2 架构伸缩  38

    3.1.3 静态内容伸缩  40

    3.1.4 服务器机群弹性  40

    3.1.5 数据库伸缩  40

    3.2 高可用性和韧性  41

    3.3 容错和冗余  43

    3.4 灾难恢复与业务连续性  44

    3.5 可扩展性与可重用性  45

    3.6 易用性与可访问性  46

    3.7 可移植性与互操作性  47

    3.8 卓越运维与可维护性  48

    3.9 安全性与合规性  49

    3.9.1 认证和授权  49

    3.9.2 Web安全  50

    3.9.3 网络安全  50

    3.9.4 基础设施安全  50

    3.9.5 数据安全  50

    3.10 成本优化与预算  51

    3.11 小结  52

    第4章 解决方案架构的设计原则  53

    4.1 工作负载的伸缩  54

    4.1.1 可预测伸缩  54

    4.1.2 被动伸缩  56

    4.2 构建有韧性的架构  56

    4.3 性能设计  58

    4.4 使用可替换资源  59

    4.5 考虑松耦合  60

    4.6 考虑服务而非服务器  62

    4.7 根据合理的需求选择合适的存储  63

    4.8 考虑数据驱动的设计  65

    4.9 克服约束  65

    4.10 安全无处不在  67

    4.11 自动化一切  67

    4.12 小结  68

    第5章 云迁移和混合云架构设计  70

    5.1 云原生架构的好处  71

    5.2 创建云迁移策略  72

    5.2.1 Lift and Shift方法  73

    5.2.2 云原生方法  75

    5.2.3 Retain or Retire方法  76

    5.3 云迁移的步骤  77

    5.3.1 发现工作负载  78

    5.3.2 分析信息  79

    5.3.3 制订迁移计划  80

    5.3.4 设计应用程序  83

    5.3.5 执行应用程序迁移上云  85

    5.3.6 集成、验证和切换  87

    5.3.7 运维云应用程序  89

    5.3.8 云上应用程序优化  90

    5.4 创建混合云架构  91

    5.5 设计云原生架构  92

    5.6 主流的公有云  94

    5.7 小结  95

    5.8 进一步阅读  95

    第6章 解决方案架构设计模式  96

    6.1 构建N层架构  97

    6.1.1 Web层  97

    6.1.2 应用层  99

    6.1.3 数据库层  99

    6.2 创建基于SaaS的多租户架构  99

    6.3 构建无状态和有状态的架构  101

    6.4 理解SOA  103

    6.4.1 基于SOAP的Web服务架构  103

    6.4.2 RESTful Web服务架构  105

    6.4.3 构建基于SOA的电子商务网站架构  106

    6.5 构建无服务器架构  107

    6.6 创建微服务架构  109

    6.7 构建基于队列的架构  111

    6.7.1 队列链表模式  112

    6.7.2 作业观察者模式  113

    6.8 创建事件驱动架构  114

    6.8.1 发布者/订阅者模型  114

    6.8.2 事件流模型  115

    6.9 构建基于缓存的架构  116

    6.9.1 三层Web架构中的缓存分发模式  117

    6.9.2 重命名分发模式  119

    6.9.3 缓存代理模式  120

    6.9.4 重写代理模式  121

    6.9.5 应用缓存模式  122

    6.10 理解断路器模式  123

    6.11 实现隔板模式  124

    6.12 构建浮动IP模式  125

    6.13 使用容器部署应用程序  126

    6.13.1 容器的好处  127

    6.13.2 容器化部署  128

    6.14 应用程序架构中的数据库处理  129

    6.15 避免解决方案架构中的反模式  132

    6.16 小结  133

    第7章 性能考量  134

    7.1 架构性能的设计原则  134

    7.1.1 降低延迟  135

    7.1.2 提高吞吐量  136

    7.1.3 处理并发问题  137

    7.1.4 使用缓存  138

    7.2 性能优化的技术选型  139

    7.2.1 计算能力选型  139

    7.2.2 选择存储  144

    7.2.3 选择数据库  147

    7.2.4 选择网络  149

    7.3 管理性能监控  152

    7.4 小结  153

    第8章 安全考量  155

    8.1 架构安全的设计原则  155

    8.1.1 实现认证和授权控制  156

    8.1.2 安全无处不在  156

    8.1.3 缩小爆炸半径  157

    8.1.4 时刻监控和审计一切  157

    8.1.5 自动化一切  157

    8.1.6 数据保护  157

    8.1.7 事件响应准备  158

    8.2 架构安全技术选型  158

    8.2.1 用户身份和访问管理  158

    8.2.2 处理网络安全问题  165

    8.2.3 保护应用程序及其基础设施  169

    8.2.4 数据安全  173

    8.3 安全和合规认证  178

    8.4 云的共享安全责任模型  178

    8.5 小结  180

    第9章 架构可靠性考量  182

    9.1 架构可靠性的设计原则  182

    9.1.1 使系统自愈  183

    9.1.2 实现自动化  183

    9.1.3 创建分布式系统  184

    9.1.4 容量监控  184

    9.1.5 验证恢复过程  184

    9.2 架构可靠性的技术选型  185

    9.2.1 规划RTO和RPO  185

    9.2.2 数据复制  186

    9.2.3 规划灾难恢复  188

    9.2.4 灾难恢复的最佳实践  195

    9.3 利用云来提高可靠性  196

    9.4 小结  197

    第10章 卓越运维考量  198

    10.1 卓越运维的设计原则  199

    10.1.1 自动化运维  199

    10.1.2 进行增量和可逆的变更  199

    10.1.3 预测并响应故障  200

    10.1.4 从错误中学习并改进  200

    10.1.5 持续更新运维手册  200

    10.2 卓越运维的技术选型  201

    10.2.1 卓越运维的规划阶段  201

    10.2.2 卓越运维的执行阶段  204

    10.2.3 卓越运维的改进阶段  210

    10.3 在公有云中实现卓越运维  212

    10.4 小结  213

    第11章 成本考量  215

    11.1 成本优化的设计原则  215

    11.1.1 计算总拥有成本  216

    11.1.2 规划预算和预测  217

    11.1.3 管理需求和服务目录  218

    11.1.4 跟踪支出  219

    11.1.5 持续成本优化  219

    11.2 成本优化的技术选型  220

    11.2.1 降低架构复杂度  220

    11.2.2 提高IT效率  221

    11.2.3 实现标准化和架构治理  222

    11.2.4 成本监控和报告  224

    11.3 公有云上的成本优化  227

    11.4 小结  228

    第12章 DevOps和解决方案架构框架  230

    12.1 DevOps介绍  231

    12.2 DevOps的好处  231

    12.3 DevOps的组成部分  232

    12.3.1 CI/CD  233

    12.3.2 持续监控和改进  234

    12.3.3 基础设施即代码  235

    12.3.4 配置管理  235

    12.4 什么是DevSecOps  236

    12.5 结合DevSecOps和CI/CD  237

    12.6 实施CD策略  238

    12.6.1 就地部署  238

    12.6.2 滚动部署  238

    12.6.3 蓝绿部署  238

    12.6.4 红黑部署  239

    12.6.5 不可变部署  240

    12.7 在CI/CD流水线中实施持续测试  240

    12.8 CI/CD的DevOps工具  242

    12.8.1 代码编辑器  243

    12.8.2 源代码管理  243

    12.8.3 CI服务器  243

    12.8.4 代码部署  245

    12.8.5 代码流水线  246

    12.9 实施DevOps最佳实践  247

    12.10 小结  248

    第13章 数据工程和机器学习  249

    13.1 什么是大数据架构  250

    13.2 大数据处理流水线设计  251

    13.3 数据摄取  252

    13.3.1 数据摄取的技术选型  253

    13.3.2 数据摄取上云  254

    13.4 数据存储  255

    13.5 数据处理和分析  262

    13.6 数据可视化  265

    13.7 理解物联网  266

    13.8 什么是机器学习  267

    13.9 使用数据科学和机器学习  268

    13.10 评估机器学习模型:过拟合与欠拟合  270

    13.11 了解监督学习和无监督学习  270

    13.12 小结  272

    第14章 遗留系统架构设计  273

    14.1 遗留系统面临的挑战  274

    14.1.1 难以满足用户需求  274

    14.1.2 维护和更新费用较高  275

    14.1.3 缺乏技能和文档  275

    14.1.4 存在安全风险  276

    14.1.5 无法兼容其他系统  276

    14.2 遗留系统现代化改造策略  277

    14.2.1 系统现代化改造的好处  277

    14.2.2 遗留系统的评估  279

    14.2.3 现代化改造方案  279

    14.2.4 文档和支持  280

    14.3 遗留系统现代化改造技术  280

    14.3.1 封装、重新托管和重新平台化  281

    14.3.2 重构和重新架构  282

    14.3.3 重新设计和替换  282

    14.4 遗留系统的云迁移策略  283

    14.5 小结  284

    第15章 解决方案架构文档  285

    15.1 文档目的  285

    15.2 文档视图  286

    15.3 文档结构  288

    15.3.1 解决方案概述  289

    15.3.2 业务上下文  290

    15.3.3 概念解决方案概述  291

    15.3.4 解决方案架构  292

    15.3.5 解决方案交付  295

    15.3.6 解决方案管理  295

    15.3.7 附录  296

    15.4 解决方案架构的IT采购文档  296

    15.5 小结  297

    第16章 学习软技能,成为更优秀的解决方案架构师  298

    16.1 掌握售前技能  299

    16.2 向企业高管汇报  300

    16.3 主人翁意识和责任心  301

    16.4 定义战略执行以及目标与关键成果  301

    16.5 着眼于大局  302

    16.6 灵活性和适应性  303

    16.7 设计思维  303

    16.8 做一个动手写代码的程序员  305

    16.9 持续学习,不断进步  306

    16.10 成为他人的导师  307

    16.11 成为技术布道者和思想领袖  308

    16.12 小结  308

    上下滑动查看

    7cd4fe98fbb9f8dc9ea744712886989c.gif

    8926bf0c9962398aaba764f4cbbdc4aa.png

    扫码关注【华章计算机】视频号

    每天来听华章哥讲书

    72a791c27df49b083f0189adeaa8e54d.gif

    更多精彩回顾

    书讯 | 11月书讯(上)| 拿下这些新书,赢在起跑线

    书讯 | 11月书讯(下) | 拿下这些新书,赢在起跑线

    资讯 | 为什么 Rust 是编程的未来?

    书单 | 8本书助你零基础转行数据分析岗

    干货 | SpringBoot 实战:加载和读取资源文件内容

    收藏 | 看漫画来告诉你:什么是 “元宇宙” ?

    上新 | 【新书速递】产品经理应该知道的72件事

    3b5ef4824b347a63ec159438b5d43075.gif

    e4d56d8728957f6ad95111d425a99865.gif

    点击阅读全文购买

    展开全文
  • 亚马逊云科技认证解决方案架构师 – 专业级考试可以检验考生是否具备在亚马逊云科技平台上设计分布式应用程序和系统的先进技术技能和经验。   本次为期一天的高级研讨会面向拥有两年或两年以上在亚马逊云科技上...
  • 这是笔者参加亚马逊解决方案架构师面试第2轮的ppt,全英文演示,分享给大家,祝大家顺利通关。文中架构图可以在https://www.processon.com/i/5a781f4fe4b0615ac04c5119中搜索《AWS-解决方案架构师》克隆原文件
  • 这几年互联网行业不断孵化...所以,本文通过搜集整理云计算解决方案架构师的相关任职要求,结合自己过往的一些相关经历,梳理对于从事云计算的一些学习规划,希望有遗漏的地方,大家可以继续补充。 解决方案架构师...
  • 亚马逊云科技认证解决方案架构师 – 助理级考试旨在检验考生在亚马逊云科技上设计和部署可扩展、高度可用且具有容错能力的系统方面的专业技术知识。参加这一为期半天的中级培训可以了解考试的主题领域,并了解这些...
  • 天翼云高级解决方案架构师认证

    千次阅读 2022-04-09 16:40:34
    天翼云高级解决方案架构师认证
  • 天翼云认证解决方案架构师重点知识点串讲2022年最新版
  • 企业架构师vs解决方案架构师vs领域架构师.docx
  • 华为,解决方案架构师.docx华为,解决方案架构师.docx华为,解决方案架构师.docx华为,解决方案架构师.docx华为,解决方案架构师.docx华为,解决方案架构师.docx华为,解决方案架构师.docx华为,解决方案架构师.docx
  • 华为,解决方案架构师.pdf华为,解决方案架构师.pdf华为,解决方案架构师.pdf华为,解决方案架构师.pdf华为,解决方案架构师.pdf华为,解决方案架构师.pdf华为,解决方案架构师.pdf华为,解决方案架构师.pdf
  • AWS解决方案架构师认证

    千次阅读 2021-08-03 17:44:36
    包含:运维、架构、开发、AI、大数据、安全这几个领域。 目前,AWS在全球云计算市场仍占有最高的市场份额,很多大型跨国企业都在使用由AWS提供的云服务。在一些以AWS为主力云平台的企业,甚至对技术人员提出了必须...
  • 本文将给那些想成为AWS解决方案架构师的IT专业人士一些参考。 AWS 解决方案架构师面试问题和回答 结论 当今云计算正在快速成为企业的必备,企业希望更大的灵活性、更高的效率、更低的成本和更好的灾难恢复——...
  • 天翼云高级解决方案架构师认证大纲
  • 天翼云高级解决方案架构师考点

    千次阅读 热门讨论 2021-11-24 09:37:05
    考试很难,90分钟,单选一半45,多选一半45,判断题10分.干货附件上传不了。。私聊
  • 根据2017 Project and Portfolio Management Landscape总结,Planview调查的49%的公司在过去12个月内都遭遇过项目失败。...解决方案架构属于在任何技术解决方案开发以前执行的最重要实践之一。在本文中,...
  • 持有AWS 认证解决方案架构师认证,薪资平均159,033 美元,超过100万人民币。培训机构Global Knowledge发布了全球IT认证薪酬调查报告,并列出了薪酬最高的15个IT认证,AWS Solutions Architect名列第三。 AWS 解决...
  • 天翼云架构师考试练习题

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 145,409
精华内容 58,163
关键字:

解决方案架构师