Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
48 lines (24 sloc) 4.57 KB

返回目录

微服务与云原生架构

本篇着眼于从单体分层架构、SOA 服务化架构、微服务架构到云原生架构衍化过程中的理论与实践。

mindmap

单体分层架构

在 Web 应用程序发展的早期,大部分工程是将所有的服务端功能模块打包到单个巨石型(Monolith)应用中,譬如很多企业的 Java 应用程序打包为 war 包,最终会形成如下的架构:

巨石型应用易于搭建开发环境、易于测试、易于部署;其缺陷也非常明显,无法进行局部改动与部署,编译时间过长,回归测试周期过长,开发效率降低等。集中式架构分为标准的三层:数据访问层、服务层和 Web 层。

SOA 面向服务架构

SOA 面向服务架构,是在互联网应用规模迅速增长,集中式架构已无法做到无限制地提升系统的吞吐量的背景下,产生的涉及模块化开发、分布式扩展部署等相对宽泛的概念。SOA 涉及具体服务在业务、架构和开发方面的实施,在架构体系上包括服务治理、服务编排等内容。

由于分布式系统十分复杂,因此产生了大量的用于简化分布式系统开发的分布式中间件和分布式数据库,服务化的架构设计理念也被越来越多的公司所认同。如下是 Dubbo 官方文档公布了一张有关 SOA 系统演化过程的图片:

SOA 往往通过服务接口来通讯,面向服务的设计模式,最终需要总线集成服务,而且大部分时候还共享数据库,出现单点故障的时候会导致总线层面的故障,更进一步可能会把数据库拖垮,因此也需要更加独立的设计方案的出现。

MSA 微服务架构

微服务(Microservices Architecture Pattern)由 Martin Fowler 在 2014 年提出的,是希望将某个单一的单体应用,转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合,从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律(Conway’s Law)所言,任何组织在设计一套系统(广义概念)时,所交付的设计方案在结构上都与该组织的通信结构保持一致,微服务与微前端不仅仅是技术架构的变化,还包含了组织方式、沟通方式的变化。

对于微服务,不同背景的人也有不同的见解,对于熟悉 SOA 的开发者,微服务也可以认为是去除了 ESB 的 SOA 的一种实现方案;ESB 是 SOA 架构中的中心总线,设计图形应该是星形的,而微服务是去中心化的分布式软件架构。微服务与微前端原理和软件工程,面向对象设计中的原理同样相通,都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。

Cloud Native 云原生架构

随着公共云将承载越来越多的算力,未来云计算将是主流的 IT 能力交付方式。而云原生是保障系统能力灵动性地有效抓手;云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用;云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API 等。这些技术组合搭配,能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。

微服务架构非常适合云原生应用程序,云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序。这意味着,如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上,我们的应用程序就是云原生的。但是,云原生同样存在着一定的限制,如果你的云原生应用程序部署在 AWS 等公有云上,则云原生 API 不是跨云平台的。因此,应用程序中使用的 DynamoDB 数据库 API 仅适用于 AWS,但不适用于 Azure,因为 DynamoDB 仅属于 AWS。API 也永远不会在本地环境中工作,因为 DynamoDB 在生产中只能在 AWS 中用。

链接

You can’t perform that action at this time.