目录

架构制图

目录

[TOC]

架构制图

SOLID 原则是一套比较经典且流行的架构原则(主要还是名字起得好):

  • 单一职责:与 Unix 哲学所倡导的“Do one thing and do it well”不谋而合;
  • 开闭原则:用新增(扩展)来取代修改(破坏现有封装),这与函数式的 immutable 思想也有异曲同工之妙;
  • 里式替换:父类能够出现的地方子类一定能够出现,这样它们之间才算是具备继承的“Is-A”关系;
  • 接口隔离:不要让一个类依赖另一个类中用不到的接口,简单说就是最小化组件之间的接口依赖和耦合;
  • 依赖反转:依赖抽象类与接口,而不是具体实现;让低层次模块依赖高层次模块的稳定抽象,实现解耦。

架构模式


架构模式总结

serverless

Serverless是BaaS+FaaS,其中云函数是核心要素。所谓云函数,实际上就是将我们传统代码,拆分成了更细的颗粒,部署在云端。这就是所谓的云函数,这些函数可以提供服务,FaaS=Function as a service。

在传统业务中,开发上线需要团队每个人开发一部分,然后合并代码联调,然后再进行测试环境部署,正式环境部署,运维等。但在云函数时代下,开发者只需要开发自己的那部分函数即可。

Serverless是一种概念而不是某种技术,可以让开发周期简化到极致,基本上写完业务代码一扔就ok了。

Serverless以后一定成为云计算的主流,不是技术决定的,是经济活动的发展规律决定的,是必然的。

IT软件研发的趋势也将从全能手转到只关注具体点上,专业的人做专业的事情,分工明确,释放开发人员的精力,只专注真正有价值的事情。

未来零代码+Serverless将是绝配,利用零代码平台可视化拖拽实现通用性需求,而对于个性化需求,又通过Serverless实现。开发人员要做的事情专注到云函数即可。业务人员通过组装来实现自己的需求。

serverless不适合长时间运行的应用

serverless 在请求到来的时候才运行,当应用不运行的时候会进入 “休眠状态”,下次当请求来临时,应用将会需要一个启动时间,可以叫 冷启动,如果我们的应用需要一直长期不间断的运行,处理大量的请求,那么可能就不适合使用serverless来架构了,如果这种情况下,我们需要使用像EC2这样的云服务器会是一个更好的选择。

EC2相当于我们自己买了一辆车,在Lambda 相当于我们租了一辆车。如果我们长期租车的话,那么肯定比买车更贵,但是租车可以减少一部分车维护成本。

这也决定serverless无法用于高并发应用

事件驱动架构

软件架构之事件驱动架构

6种事件驱动的架构模式

分层架构

传统三层架构 与 领域驱动设计中的 四层架构

一篇文章读懂分层架构

微内核架构

微内核架构(Microkernel Architecture),也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构

eg:idea插件、中台扩展点、规则引擎

37 - 微内核架构详解

P2P架构

peer to peer, 点对点架构,又称对等网络

什么是对等网络?对等网络(P2P)的特点与三大应用


接口隔离原则(ISP)

  • 简单地说,就是使用多个专门的接口比使用单个接口要好很多。

  • ISP强调的是接口对客户端的承诺越少越好,并且要做到专一。

  • 对于接口的污染,可以考虑这两条处理方式:

    • 利用委托分离接口。
    • 利用多继承分离接口。

    委托模式中,有两个对象参与处理同一个请求,接受请求的对象将请求委托给另一个对象来处理,如策略模式、代理模式等中都应用到了委托的概念。


微服务与云原生的关系

微服务是云原生的事实标准

作者:倚天码农 链接:https://www.zhihu.com/question/361320719/answer/939015726 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

关于云原生的定义,其中比较有影响力的是“云原生计算基金会”的定义,简略如下:

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。“

它把微服务作为云原生的代表技术,我觉得是不妥的。云原生和微服务是两个不同维度的东西。 云原生更侧重应用程序的运行环境, 它是以k8s和容器为基础的云环境。“云原生计算基金会”致力于打造一整套工具来帮助应用程序从开发,测试,运行以及部署到云环境。

微服务是应用程序的软件架构,可以是单体式和微服务式。 微服务是基于分布式计算的。 你的应用程序即使不采用微服务架构也可以是云原生的,例如分布式的,但效果没有微服务好。 如果是单体式的,云原生就基本发挥不出什么优势。 另外微服务的程序也可以不是云原生的。它们虽然是两个不同的东西,但云原生和微服务是天生良配,相得益彰,相辅相成。 而且很多云原生的工具都是针对微服务架构设计的。

你可以说现代应用程序的趋势就是"微服务+云原生"

微服务与服务网格

微服务架构的优点很多,比如它解耦业务,提供更高的灵活性,允许在服务频繁发版的同时保持系统其它部分的可用性与稳定性;解耦编程语言,针对不同业务可以使用更加合适的语言进行开发;解耦开发团队,不同团队各自负责一个微服务,互不影响,加速交付。

以spring cloud微服务核心组件包括以下几个组件:

  • Config:配置中心
  • Eureka:服务治理组件,包含服务注册与发现
  • Hystrix:容错管理组件,实现了熔断器
  • Ribbon:客户端负载均衡的服务调用组件
  • Feign:基于Ribbon和Hystrix的声明式服务调用组件
  • Zuul:网关组件,提供智能路由、访问过滤等功能

Service Mesh 有如下几个特点:

  • 应用程序间通讯的中间层
  • 轻量级网络代理
  • 应用程序无感知
  • 解耦应用程序的重试/超时、监控、追踪和服务发现以Istio为例:

http://img.cana.space/picStore/20220426141439.png

关于微服务和服务网格的区别:

微服务更像是一个服务之间的生态,专注于服务治理等方面,而服务网格更专注于服务之间的通信,以及和 DevOps 更好的结合

为什么需要服务网格?

从微服务和服务网格的对比和区别来看,其实很明确了,为什么有了微服务还需要服务网格。

Service Mesh作为服务间通信的基础设施层,可以将它比作是应用程序或者说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层(比如通过 HTTP 协议的 RESTful 应用),同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情,比如 Spring Cloud、OSS,现在只要交给 Service Mesh 就可以了。


有了微服务为什么还需要服务网格(service mesh)?

服务网格是用于微服务应用的可配置基础架构层,把微服务的各个service(服务)节点,用一张mesh(网格)连接起来,使每个service实例之间的通信更加流畅、可靠和迅速,解决服务之间的通信、监视系统运行状况、处理多点故障等问题。服务网格有以下的核心功能:

  • 负载均衡
  • 服务发现
  • 认证方式
  • 流量管理和路由
  • 断路器和故障转移
  • 安全管理
  • 指标收集和监控
  • 故障注入

与传统微服务框架相比,服务网格通过Sidecar模式,将业务与治理解耦,微服务治理能力下沉至运维层,降低开发难度,在架构上更容易实现层次化、规范化、体系化。

http://img.cana.space/picStore/20220426141809.png


sidecar架构模式

如果你最近经常看一些技术型的文章,可能会看到这个技术名词:Sidecar 模式。中文译名为:挎斗模式。这个名字为直译,挎斗就是这样的一种摩托车:

http://img.cana.space/picStore/20220426142020.png

如果理解了这种模式,就会明白这个名字其实取得特别好。Sidecar 模式就是指在原来的业务逻辑上再新加一个抽象层。这种模式很好的印证了那个计算机的名言:

“计算机科学领域的任何问题都可以通过增加一个简介的中间层来解决。” “Any problem in computer science can be solved by another layer of indirection.”

如果一个抽象层不够,那来两个。这种模式也不是近些年新发明的,我们可以理解 Nginx 的反向代理其实也算一种 sidecar 模式。只是近些年,随着微服务和容器化在实践中越来越多,这种模式的使用范围也更广了。

Sidecar 架构模式


富客户端是和瘦客户端相对应的。

通俗点说,最初的web浏览器就是瘦客户端,因为客户端只是一个浏览器,所有的其他功能都必须在服务端实现。目前由于flash,sliverlight等客户端插件的流行,就可以把很多功能放在客户端进行,这种实现,就是富客户端

“经过这几年的技术迭代,公司的绝大部分系统已经微服务化,不过有些中间件没有业务场景的监控能力,富客户端SDK方式接入中间件,也让中间件的能力迭代很困难。”

这儿说的富客户端是指应用程序和中间件,应用程序接入中间件比较重,导致中间件能力迭代困难