分(fēn)布式软件體(tǐ)系架构

分(fēn)布式软件體(tǐ)系架构
    马上咨询

    张逸  现為(wèi)深圳大眼科(kē)技有(yǒu)限公司的首席架构师,联合创始人  > 

    先后就职于中兴通讯、惠普GDCC、中软國(guó)际、ThoughtWorks等大型中外企业,任职角色為(wèi)高级软件工程师,架构师,技术总监,首席咨询师。精通包括C#、Java、Ruby、Scala、Python、JavaScript等多(duō)种语言,熟练掌握面向对象思想、领域驱动设计、函数式语言、架构、大数据分(fēn)析、敏捷与过程改进,并致力于大型软件企业的面向服務(wù)系统架构设计以及互联网Web系统架构设计。在ThoughtWorks期间,作為(wèi)一名咨询师,主要為(wèi)客户提供组织的敏捷转型、过程改进、系统架构监理(lǐ)、领域设计、代码质量提升等咨询工作。目前,作為(wèi)公司产品的架构师,致力于商(shāng)业智能(néng)产品与大数据分(fēn)析平台的开发与架构设计。

    课程简介

    随着互联网的发展,大型分(fēn)布式系统也越来越多(duō)、越来越复杂、越来越重要。如何有(yǒu)效地保证大型分(fēn)布式系统7×24小(xiǎo)时全天候持续稳定地运行也就成為(wèi)了一个重要课题。

    课程大纲

    第一部分(fēn):分(fēn)布式體(tǐ)系架构基础
    1.什么是分(fēn)布式系统
    分(fēn)布式系统是一种计算系统,系统中多(duō)个组件通过网络通信的方式互联。本部分(fēn)内容将详细介绍分(fēn)布式系统的历史演进以及主要的架构特点。
    2.典型分(fēn)布式系统的演进
    引入分(fēn)布式系统,其目的是满足高并发与高性能(néng)需求。例如引入缓存、代理(lǐ)等手段改进性能(néng),又(yòu)例如在架构层面上对系统进行物(wù)理(lǐ)便捷分(fēn)割,然后通过引入消息队列或微服務(wù)实现系统的分(fēn)布式设计。
    案例分(fēn)析:订单业務(wù)模块的分(fēn)布式架构演进
    3.分(fēn)布式系统的优势与劣势
    Martin Fowler提出,分(fēn)布式系统的第一原则就是不要分(fēn)布式。之所以提出这个原则,就是告诫设计者要充分(fēn)认识到分(fēn)布式系统刚在带来优势的同时,自身的劣势可(kě)能(néng)会给系统带来障碍。
    第二部分(fēn):基于消息的分(fēn)布式架构
    1.常见的消息模式
    介绍在企业分(fēn)布式应用(yòng)开发中常见的消息模式,如消息通道模式、发布者-订阅者模式、消息路由模式等。
    2.主流的消息队列中间件
    介绍主流的消息队列中间件,包括RabbitMQ、ActiveMQ、ZeroMQ、AKKA与目前最為(wèi)流行的Kafka。分(fēn)析它们各自的特性,对比这些中间件,给出合适的运用(yòng)场景,并介绍技术决策的方法。
    案例分(fēn)析:医疗卫生知识库系统。通过引入消息队列改善系统架构的质量。
    3.消息队列的设计原理(lǐ)
    深入探讨消息队列中间件的核心原理(lǐ)与设计思想,包括消息队列的架构、队列实现的基本功能(néng)与高级特性。
    4.KAFKA分(fēn)布式消息系统
    介绍目前最為(wèi)流行的分(fēn)布式消息系统Kafka,包括Kafka的设计架构、组成元素和应用(yòng)场景。同事,还将介绍Kafka与大数据流式处理(lǐ)的结合。
    案例分(fēn)析:某手机场上的实时数据监控告警系统
    第三部分(fēn):REST架构风格
    REST描述了Web作為(wèi)一个分(fēn)布式超媒體(tǐ)的应用(yòng),相互链接的资源通过交换代表资源状态的表述来进行通信。它是WEB系统架构运用(yòng)最為(wèi)广泛的架构风格。
    1.理(lǐ)解REST的五个关键字
    要深入理(lǐ)解REST,需要理(lǐ)解REST的五个关键词,包括:资源(Resource)、资源的表述(Representation)、状态转移(State Transfer)、统一接口(Uniform Interface)、超文(wén)本驱动(Hypertext Driven)。
    2.REST的主要特征
    REST风格的架构所具有(yǒu)的6个主要特征,包括:面向资源(Resource Oriented)、可(kě)寻址(Addressability)、连通性(Connectedness)、无状态(Statelessness)、统一接口(Uniform Interface)、超文(wén)本驱动(Hypertext Driven)。
    3.REST的API设计
    采用(yòng)Restful风格的架构设计,在API设计上,需要遵循REST的设计原则,它与传统的Web Service APIs设计以及组件的APIs设计并不相同,而是面向资源的角度考虑API的定义与设计。
    案例分(fēn)析:某BI产品的REST API设计
    第四部分(fēn):微服務(wù)架构风格
    1.面向服務(wù)的软件架构
    面向服務(wù)體(tǐ)系架构(SOA)的风格在过去10年中已经成為(wèi)设计大型分(fēn)布式系统的主流模式。SOA背后的核心思想是设计一个作為(wèi)交互服務(wù)网络的系统。服務(wù)通过定义良好的接口提供清晰具體(tǐ)的功能(néng)。
    案例分(fēn)析:瑞士信贷的SOA架构
    2.微服務(wù)架构的核心概念与特征
    微服務(wù)设计是一个考量各方因素下的一个决策的过程,它提倡建立细粒度的独立服務(wù),且服務(wù)支持物(wù)理(lǐ)上的单独部署,以便于更好地重用(yòng)服務(wù)、满足服務(wù)水平伸缩与独立运维的需求。
    案例分(fēn)析:某BI产品的微服務(wù)架构
    3.如何分(fēn)解服務(wù)
    在设计层面,该如何界定微服務(wù)的边界,并确定服務(wù)与服務(wù)之间的通信方式。这牵涉到许多(duō)架构设计因素,包括可(kě)重用(yòng)行,可(kě)扩展性,数据一致性以及部署等诸多(duō)方面。本部分(fēn)将通过对Data Schema、DDD中的BoundedContext、、六边形架构模型等内容综合分(fēn)析微服務(wù)的分(fēn)解与设计。
    4.CQRS与Event Sourcing
    CQRS不仅限于微服務(wù)架构,但在微服務(wù)架构中,会被频繁地与Event Sourcing结合,并以事件驱动架构(EDA)思想来解决一些高并发和数据一致性问题。
    5.微服務(wù)架构的数据一致性
    分(fēn)析传统的本地事務(wù)与分(fēn)布式事務(wù)如何保证数据的一致性,然后讲解在微服務(wù)架构中,如何结合CAP原则实现数据一致性。
    6.从单體(tǐ)架构到微服務(wù)架构
    多(duō)数情况下,微服務(wù)架构都不是一蹴而就的,即使是一个新(xīn)项目,保守起见,也建议从一开始设计為(wèi)单體(tǐ)架构,只要在合适的情况下,才需要将架构演进到微服務(wù)架构。本部分(fēn)将会介绍在这个演进过程中我们需要关注的问题,以及具體(tǐ)的实施路径。
    7.微服務(wù)的监控与告警
    在微服務(wù)架构中,每个服務(wù)都是一个可(kě)以独立运行的业務(wù)单元,同时每个服務(wù)都运行在独立的节点上。因此,我们需要為(wèi)每个服務(wù)建立独立的监控以及告警机制,以监控服務(wù)的健康状况,并保证在异常发生时,随时恢复。本部分(fēn)将介绍如何利用(yòng)Nagios对微服務(wù)进行监控,以及Nagios的工作原理(lǐ)。
    案例分(fēn)析:某金融系统的微服務(wù)演进
    第五部分(fēn) MMN:面向企业的架构设计过程
    MMN架构设计过程是指对系统架构从宏观、微观与纳米层面的整體(tǐ)设计过程。这是一个迭代和演进的设计过程,通过自顶向下结合自下而上的方式,对整个软件系统进行分(fēn)析与设计,保证整个软件系统满足功能(néng)需求与质量属性。在整个架构设计过程中,会运用(yòng)UML、OOAD、UDD和DDD等方法论,遵循MMN(宏观-微观-纳米)的层次对整个系统进行架构梳理(lǐ)和设计。
    1.宏观视图的架构因素与设计过程
    • 定义架构概图
      包括调查架构资源,明确架构的目标,根据架构目标作出重要的设计决策,并分(fēn)析主要的用(yòng)例场景,以建立一个粗略的架构概图。
      案例分(fēn)析:企业应用(yòng)套件的架构概图
    • 架构全局分(fēn)析
      识别架构风险,并确定风险优先级。然后根据识别出来的风险编写架构因素表,制定具體(tǐ)的架构策略。同时确定整个系统的关键场景。
      案例分(fēn)析:遠(yuǎn)程访问的架构策略
    • 构建概念模型
      确定技术框架与技术选型,识别并分(fēn)析软件产品的设计约束,从而确定架构风格,并根据具體(tǐ)场景运用(yòng)架构模式。最后,建立系统的逻辑视图和物(wù)理(lǐ)视图。
      案例分(fēn)析:CIMS架构概念模型
    2.微观视图的架构因素与设计过程
    • 细化逻辑视图
      进行领域分(fēn)析,确定系统的应用(yòng)逻辑架构与业務(wù)逻辑架构,并设计整个系统的模块视图。
      案例分(fēn)析:燃气集团解决方案
    • 纳米视图的架构因素与设计过程
      构建设计模型:讲解职责驱动设计,通过角色、职责与协作完成对象的职责分(fēn)配,并通过识别变化点,利用(yòng)抽象对变化进行封装,以及合理(lǐ)运用(yòng)设计模式。
    • 代码视图:包括确定部署组件、配置管理(lǐ)、持续集成等与代码级别有(yǒu)关的内容。
      案例分(fēn)析:数据分(fēn)析器;商(shāng)业智能(néng)SaaS平台引擎设计;商(shāng)业智能(néng)SaaS平台的代码视图
    第六部分(fēn):架构关注点专题讨论
    专题一:高性能(néng)系统的设计
    高性能(néng)是软件系统设计无法绕过的话题,无论是企业架构还是互联网架构,设计时都需要考虑如何满足高性能(néng)的要求,尤其是在数据量越来越大,并发访问越来越多(duō)的前提下,高性能(néng)会成為(wèi)架构师必须要解决的问题。
    本专题讨论会给出高性能(néng)设计的常见问题、解决方案与最佳实践。
    案例分(fēn)析:Twitter的高性能(néng)分(fēn)布式日志(zhì),满足了系统的可(kě)靠性、高吞吐量、低延迟、可(kě)扩展性等质量属性。
    专题二:分(fēn)布式事務(wù)
    当今的大型软件系统都是分(fēn)布式系统,随着硬件成本的逐渐降低,网络宽带的逐步增加,我们已经告别单机时代。分(fēn)布式系统可(kě)以更大限度地利用(yòng)硬件的水平扩展,也能(néng)够保证异构、异步系统的集成,但是带来的问题也很(hěn)显著,除了运维方面的挑战外,如何保证业務(wù)服務(wù)的事務(wù),成了棘手的问题。
    本专题会介绍分(fēn)布式事務(wù)ACID约束的问题,并讲解BASE原则以及CAD原理(lǐ)。
    案例分(fēn)析:通过对支付宝扣款到余额宝的案例分(fēn)析分(fēn)布式事務(wù)的解决方案。
    专题三:大数据处理(lǐ)
    大数据处理(lǐ)成為(wèi)这几年最热门的话题,也是大多(duō)数软件企业需要解决的问题:即如何在海量数据中寻找到业務(wù)价值。本专题会从技术角度剖析大数据技术生态圈,并主要介绍Hadoop、Spark等大数据主流技术与平台框架。
    案例分(fēn)析:Airbnb数据基础设施的主要架构