写点什么

架构师训练营 -week10- 总结

用户头像
大刘
关注
发布于: 2020 年 11 月 27 日
架构师训练营 -week10-总结
本周重点学习了以下几个方面的内容:
  1. 微服务的演进过程

  2. 微服务落地实践经验

  3. 微服务网关技术剖析

  4. DDD 和组件设计原则


架构演进过程:单体架构 -> SOA 时代 -> 微服务时代

单体架构和微服务的分布式架构的优缺点比较:

分布式系统架构的难点在于系统设计,以及管理和运维。所以,分布式架构解决了“单点”和“性能容量”的问题,但却新增了一堆问题。而对于这些新增的问题,还会衍生出更多的子问题,这就需要我们不断地用各式各样的技术和手段来解决这些问题。这就出现了我前面所说的那些架构方式,以及各种相关的管理型的技术方法。这个世界就是这样变得复杂起来的。


提高系统性能的常用技术手段:


提高系统稳定性的常用手段:


微服务具备的 9 大特征:

第一,围绕业务能力构建(Organized around Business Capabilities)

这个核心技术特征,实际上再次强调了康威定律的重要性。它的意思是,有怎样的结构、规模和能力的团队,就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合,而是必然的演化结果。


第二,分散治理(Decentralized Governance)

这个技术特征,表达的是“谁家孩子谁来管”。微服务对应的开发团队,有着直接对服务运行质量负责的责任,也应该有着不受外界干预,掌控服务各个方面的权力,可以选择与其他服务异构的技术来实现自己的服务。

微服务更加强调的是,在确实有必要进行技术异构的时候,一个开发团队应该能有选择“不统一”的权利。比如说,我们不应该强迫用 Node.js 去开发报表页面;要做人工智能计算的时候,也可以选择用 Python,等等。


第三,通过服务来实现独立自治的组件(Componentization via Services)


第四,产品化思维(Products not Projects)

产品化思维的意思就是,我们要避免把软件研发看作是要去完成某种功能,而要把它当做是一种持续改进、提升的过程。比如,我们不应该把运维看作就是运维团队的事,把开发看作就是开发团队的事。

以前在单体的架构模式下,程序的规模决定了我们无法让全部的开发人员,都关注到一个完整的产品,在组织中会有开发、运维、支持等细致分工的成员,他们只关注于自己的一块工作。但在微服务下,我们可以让团队中的每一位成员,都具有产品化思维。因为在“2 Pizza Tems”的团队规模下,每一个人都了解全过程是完全有可能实现的。


第五,数据去中心化(Decentralized Data Management)

微服务这种架构模式也明确地提倡,数据应该按领域来分散管理、更新、维护和存储。

在单体服务中,通常一个系统的各个功能模块会使用同一个数据库,虽然这种中心化的存储确实天生就更容易避免一致性的问题,但是,同一个数据实体在不同服务的视角里,它的抽象形态往往也是不同的。

尽管在分布式中,我们要想处理好一致性的问题也很困难,很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻,一致性问题这些必要的代价是值得付出的。


第六,轻量级通讯机制(Smart Endpoints and Dumb Pipes)

ESB 可以处理消息的编码加工、业务规则转换等;BPM 可以集中编排企业的业务服务;SOAP 有几十个 WS-* 协议族在处理事务、一致性、认证授权等一系列工作。这些构筑在通讯管道上的功能,也许在某个系统中的确有一部分服务是需要的,但对于另外更多的服务来说是强加进来的负担。

如果服务需要上面的某一种功能或能力,那就应该在服务自己的 Endpoint(端点)上解决,而不是在通讯管道上一揽子处理。

微服务提倡的是类似于经典 Unix 过滤器那样,简单直接的通讯方式。比如说,RESTful 风格的通讯,在微服务中就是比较适合的。


第七,容错性设计(Design for Failure)

容错性设计,是指软件架构不再虚幻地追求服务永远稳定,而是接受服务总会出错的现实。

可靠系统完全可以由会出错的服务来组成,这是微服务最大的价值所在。


第八,演进式设计(Evolutionary Design)

容错性设计承认服务会出错,而演进式设计则是承认服务会被报废淘汰。

一个良好设计的服务,应该是能够报废的,而不是期望得到长久的发展。如果一个系统中出现不可更改、无可替代的服务,这并不能说明这个服务有多么重要,反而是系统设计上脆弱的表现。微服务带来的独立、自治,也是在反对这种脆弱性。


第九,基础设施自动化(Infrastructure Automation)

基础设施自动化,如 CI/CD 的长足发展,大大降低了构建、发布、运维工作的复杂性。

由于微服务架构下,运维的服务数量比起单体架构来说,要有数量级的增长,所以使用微服务的团队,会更加依赖于基础设施的自动化。毕竟,人工是无法运维成百上千,乃至成千上万级别的服务的。


以上 9 个特征,是一个合理的微服务系统展示出来的内、外在表现,它能够指导你该如何应用微服务架构,却不必作为一种强加于系统中的束缚来看待。


落地实践中的知识点,把这周涉及到的列出来:

  • Dubbo 框架


  • CQRS:命令与查询职责隔离,读写分离

  • 事件溯源:将用户请求处理过程中的每次状态变化都记录到事件日志中,并按时间序列进行持久化存储

  • 微服务网关:统一接入、安全防护、流量管控与容错、协议适配

  • 开放授权协议 Oauth2.0


领域驱动设计(Domain Driven Design,简称 DDD):

DDD 是一种处理高度复杂领域的设计思想,它试图分离技术实现的复杂性,并围绕业务概念构建领域模型来控制业务的复杂性,以解决软件难以理解,难以演进的问题。DDD 不是架构,而是一种架构设计方法论,它通过边界划分将复杂业务领域简单化,帮我们设计出清晰的领域和应用边界,可以很容易地实现架构演进。


DDD 包括战略设计和战术设计两部分。

战略设计主要从业务视角出发,建立业务领域模型,划分领域边界,建立通用语言的限界上下文,限界上下文可以作为微服务设计的参考边界。

战术设计则从技术视角出发,侧重于领域模型的技术实现,完成软件开发和落地,包括:聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。


领域:领域是一个组织所做的事情以及其包含的一切,通俗的说,就是组织的业务范围和做事方式,也是软件开发的目标范围。



  • DDD 主要关注:从业务领域视角划分领域边界,构建通用语言进行高效沟通,通过业务抽象,建立领域模型,维持业务和代码的逻辑一致性。

  • 微服务主要关注:运行时的进程间通信、容错和故障隔离,实现去中心化数据管理和去中心化服务治理,关注微服务的独立开发、测试、构建和部署。


贫血模型 VS 充血模型:

基于贫血模型的传统的开发模式,比较适合业务比较简单的系统开发。

相对应的,基于充血模型的 DDD 开发模式,更适合业务复杂的系统开发。比如,包含各种利息计算模型、还款模型等复杂业务的金融系统。

我们平时做 Web 项目的业务开发,大部分都是基于贫血模型的 MVC 三层架构,在专栏中我把它称为传统的开发模式。之所以称之为“传统”,是相对于新兴的基于充血模型的 DDD 开发模式来说的。基于贫血模型的传统开发模式,是典型的面向过程的编程风格。相反,基于充血模型的 DDD 开发模式,是典型的面向对象的编程风格。不过,DDD 也并非银弹。对于业务不复杂的系统开发来说,基于贫血模型的传统开发模式简单够用,基于充血模型的 DDD 开发模式有点大材小用,无法发挥作用。相反,对于业务复杂的系统开发来说,基于充血模型的 DDD 开发模式,因为前期需要在设计上投入更多时间和精力,来提高代码的复用性和可维护性,所以相比基于贫血模型的开发模式,更加有优势。


  • 子域:通常一个领域拆分成多个子域

  • 限界上下文:在一个子域中,会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于该边界内部的确切含义,这样的边界便称为限界上下文

  • 上下文映射图:不同的限界上下文,也就是不同的子系统或者模块之间会有各种的交互合作。DDD 使用上下文映射图来设计这种交互。

  • 实体:领域模型对象。每个实体都是唯一的,具有一个唯一标识

  • 值对象:值对象是不变的,没有行为和状态,仅仅用来作为度量或描述的对象。

  • 聚合:关联对象的集合

  • 聚合根:将多个实体和值对象聚合在一起的实体



用户头像

大刘

关注

大道至简,知易行难 2017.12.27 加入

想成为合格架构师的架构师

评论

发布
暂无评论
架构师训练营 -week10-总结