4006-998-758
3000+课程任你选择
分布式体系架构设计工作坊
研发学院 体系架构设计 产品经理
张逸

高质量编码实践者,领域驱动设计布道师,微服务系统架构师,大数据平台架构师,敏捷转型咨询师。热衷于编程语言学习与技艺提升,致力于将企业架构、精益需求管理、领域驱动设计与微服务架构完美结合,打造面向企业的业务中台;致力于将数据仓库、实时流处理、机器学习与高性能存储完美结合,打造面向行业的智能数据中台。

拥有近20年的软件开发与架构设计经验,曾先后就职于中兴通讯、惠普 GDCC、中软国际、ThoughtWorks 等大型中外企业,任职角色为高级软件工程师、架构师、技术总监、首席咨询师。精通包括 Java、Scala、Python、C#、JavaScript、Ruby 等多种语言,熟练掌握面向对象思想、测试驱动开发与重构、领域驱动设计、函数式编程、架构、大数据分析、敏捷与过程改进,并致力于大型软件企业的面向服务系统架构设计、大数据平台架构设计以及互联网 Web 系统架构设计,曾经连续四届荣获微软最有价值专家,具有丰富的企业软件系统和分布式开发经验。


查看老师详情
课程内容


课程目标


通过一个完整案例演练贯穿整个架构设计过程,内容涉及:

需求与架构目标的识别

RAIDs架构驱动方法

技术选型与决策

CQRS模式

系统一致性

领域驱动的战略设计

六边形架构

微服务架构的服务分解

架构演进

Clean Architecture思想

技术雷达

 

 课程要求

 

对培训学员进行分组,5~7人为一组,并在课前热身时挑选Leader

白板纸若干、马克笔若干、白板笔若干、即时贴若干

若有条件,应提供网络与电脑


课程特色 


以工作坊形式,通过架构设计实战贯穿整个培训过程。


课程特色

 

搭建一个技术部落,将与IT、互联网、数字领域相关的人、部落(业务、社区、兴趣组等)和内容联系起来,提供一个分享与交流的途径。在最基本的层面上,它是一个本地的博客、微博、微信文章、开源代码、活动、讲座、工作以及更多内容的聚合器。

 

课程需求


版本1业务需求:

普通用户可以通过微信、微博等社交账号登录

VIP企业用户需提供注册信息,并交纳规定的服务费用

若用户设置了相关账户信息,则个人信息上可以显示微博动态、Github提交记录等

注册用户可以创建新的技术部落

注册用户可以申请成为技术部落会员

技术部落会员可以在技术部落中分享内容

技术部落会员可以关注/收藏自己感兴趣的内容

技术部落会员可以组织线上讲座,进行网络直播。网络直播分为公益直播与收费直播

网络直播视频存储在系统服务器上,提供回看功能

注册用户可以发布活动事件

注册用户可以发布求职信息

VIP企业用户可以发布招聘信息

注册用户可以关注自己感兴趣的活动,关注后,系统会及时通知活动情况

注册用户可以对技术部落中的文章、活动、直播视频、工作以及用户进行全文本搜索

为部落与用户制定积分政策,并根据最近七天的分数滚动计算出最活跃排行榜

对整个系统中关注度高、相关度的文章进行智能推荐

为VIP企业用户提供人才推荐功能

除收费服务外,其余功能皆提供广告点击服务

 

版本1质量属性需求:

系统分为移动APP与Web应用

满足10万PV的并发请求

用户阅读分享内容的响应时间不超过2s

阅读的内容经过系统的格式化

文章推荐服务的准确度达到60%的准确度

人才推荐服务的准确度达到80%的准确度

网络直播的并发访问量能够支持10万级别,并保证直播的播放质量

全文本搜索的响应时间不超过5s

 

第一次演练:架构目标与范围

分析需求,明确整个系统的用户角色,定义系统的宏观边界,并找出与之相关的第三方系统。

知识点:

架构与分布式架构的概念

System Context

 

第二次演练:RAIDs分析

RAIDs分析即识别整个系统的风险(Risk)、假设(Assumption)、问题(Issue)与依赖(Dependency)。分析出来这些内容将成为架构设计的驱动力,作为技术选型与决策的输入。

在进行RAIDs分析之后,团队应就识别出来的风险(问题)优先级达成一致意见,并给出相对具体的架构原则;而假设与依赖则可以视为架构设计的约束。

知识点:

RAIDs分析

 

第三次演练:技术选型

结合着系统需求与RAIDs分析出来的结果,我们需要针对分布式架构的同步消息调用、异步消息调用等诸多方面进行技术选型。

在进行技术选型时,应根据具体的需求场景、质量属性、团队人员能力等诸多方面进行考量,并利用Technical Matric的方法进行评估,帮助决策。

实战:

针对RPC框架进行技术Spike

针对数据库进行技术Spike

第四次演练:关键因素分析

如果架构设计只是高层的概念设计与笼统的框架图,则设计方案就只能是空中楼阁,无法落地实施。因此,我们需要针对分布式系统架构的关键因素,从实现层面进行剖析,深入理解。

分离的原则

关注点分离原则是架构设计中应对系统复杂性的主要手段。然而分离的方向牵涉到多个层面,多种因素,包括:

前后端分离:关注视角的不同

领域逻辑分离:职责内聚性的不同

Online/Offline分离:适用场景的不同,也可以视为同步/异步的分离

容器边界分离:从部署与资料利用的角度分解

REST架构风格

REST描述了Web作为一个分布式超媒体的应用,相互链接的资源通过交换代表资源状态的表述来进行通信。它 是WEB系统架构运用最为广泛的架构风格。

通过深入理解REST架构风格,明确它的主要特征,总结REST服务设计的核心原则。

CQRS架构模式

CQRS即Command Query Responsibility Seperation(命令查询职责分离),其设计思想来源于Mayer提出的CQS(Command Query Seperation)。这种命令与查询的分离方式,可以更好地控制请求者的操作。

系统的高性能

通过引入诸如缓存、CDN、异步处理、并发处理、水平扩展等手段提高系统的性能,满足高并发访问请求。

分布式系统的一致性

主要分析在分布式系统下,如何保证数据的一致性,包括对BASE、CAP理论的深入分析,并介绍分布式系统处理一致性的常见模式。

 

第五次演练:领域驱动与微服务

领域逻辑的分离应遵循“高内聚松耦合”原则,这一分离原则尤其针对于微服务设计。在进行服务设计时,引入领域驱动设计(Domain Driven Design)的知识,通过识别Bounded Context进行微服务设计。

知识点:

Bounded Context

Context Map

六边形架构

微服务设计原则

 

第六次演练:架构演进

技术部落的需求发生了变化,要求增加如下功能:

通过网络爬虫挖掘技术网站文章,根据部落主题进行文章推荐;

为注册会员提供博客系统,用户只需要在本地编写Markdown文件,并进行同步,即可自动更新博客;

提供对主要招聘网站包括LinkedIn、100Offer等网站的集成,实时更新招聘信息;

如何在现有架构下应对需求变化,并对架构进行演进式设计。

 

工作坊总结

Clean Architecture思想

Clean Architecture提出的模型是一个可测试的模型,无需依赖于任何基础设施就可以对它进行测试,只需通过边界对象发送和接收对应的数据结构即可。它们都遵循稳定依赖原则 ,不对变化或易于变化的事物形成依赖。

技术雷达

针对整个分布式系统架构设计,从原则、模式、框架、工具四个角度设计技术雷达。


返回上一级