Introduction

返回目录

微服务与云原生架构

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

mindmap

单体分层架构

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

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

在 Web2.0 时代刚刚流行的时候,互联网应用与企业级应用并没有本质的区别,集中式架构分为标准的三层:数据访问层、服务层和 Web 层。

  • 数据访问层用于定义数据访问接口,实现对真实数据库的访问;

  • 服务层用于对应用业务逻辑进行处理;

  • Web 层用于处理异常、逻辑跳转控制、页面渲染模板等。

SOA 面向服务架构

SOA(Service-Oriented Architecture,面向服务的架构)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

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

SOA 的实施具有几个鲜明的基本特征。实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标,就要在实施 SOA 的过程中牢记以下特征:

  • 可从企业外部访问

  • 随时可用

  • 粗粒度的服务接口分级

  • 松散耦合

  • 可重用的服务

  • 服务接口设计管理

  • 标准化的服务接口

  • 支持各种消息模式

  • 精确定义的服务契约

在上图中, 服务消费者(service consumer)可以通过发送消息来调用服务。这些消息由一个服务总线(service bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引(business rules engine),该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(service management infrastructure),用来管理服务,类似审核,列表(billing),日志等功能。此外,该架构给企业提供了灵活的业务流程,更好地处理控制请求(regulatory requirement),例如 Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。

由于分布式系统十分复杂,因此产生了大量的用于简化分布式系统开发的分布式中间件和分布式数据库,服务化的架构设计理念也被越来越多的公司所认同。如下是 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)等基本的原则。

上图从三个维度概括了一个系统的扩展过程,x 轴即水平复制,即在负载均衡服务器后增加多个 web 服务器。z 轴是对数据库的扩展,即分库分表(分库是将关系紧密的表放在一台数据库服务器上,分表是因为一张表的数据太多,需要将一张表的数据通过 hash 放在不同的数据库服务器上)。y 轴是业务方向的扩展,才能将巨型应用分解为一组不同的服务,例如订单管理中心、客户信息管理中心、商品管理中心等等。

X 轴:运行多个负载均衡器之后的运行实例 Y 轴:将应用进一步分解为微服务(分库) Z 轴:大数据量时,将服务分区(分表)

SOA 与微服务的区别在于,SOA 更多强调重用,而微服务偏向于重写。SOA 偏向水平服务,微服务偏向垂直服务;SOA 偏向自上而下的设计,微服务偏向自下而上的设计。

Cloud Native 云原生架构

Pivotal 是云原生应用的提出者,并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架,成为云原生应用架构中先驱者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的小册子,其中探讨了云原生应用架构的几个主要特征:符合 12 Factors 应用、面向微服务架构、自服务敏捷架构、基于 API 的协作以及抗脆弱性。2015 年 Google 主导成立了云原生计算基金会(CNCF),起初 CNCF 对云原生(Cloud Native)的定义包含以下三个方面:应用容器化、面向微服务架构、应用支持容器的编排调度。

云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序;这意味着,如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上,我们的应用程序就是云原生的。随着公共云将承载越来越多的算力,未来云计算将是主流的 IT 能力交付方式,CNCF 也对云原生进行了重新定义:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用;云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术组合搭配,能够构建容错性好、易于管理和便于观察的松耦合系统;再结合可靠的自动化手段,云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。由此可见,云原生是保障系统能力灵动性地有效抓手;云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。微服务架构非常适合云原生应用程序;但是,云原生同样存在着一定的限制,如果你的云原生应用程序部署在 AWS 等公有云上,则云原生 API 不是跨云平台的。因此,应用程序中使用的 DynamoDB 数据库 API 仅适用于 AWS,但不适用于 Azure,因为 DynamoDB 仅属于 AWS;API 也永远不会在本地环境中工作,因为 DynamoDB 在生产中只能在 AWS 中用。

Serverless 无服务器是一种架构理念,其核心思想是将提供服务资源的基础设施抽象成各种服务,以 API 接口的方式供给用户按需调用,真正做到按需伸缩、按使用收费。消除了对传统的海量持续在线服务器组件的需求,降低了开发和运维的复杂性,降低运营成本并缩短了业务系统的交付周期,使得用户能够专注在价值密度更高的业务逻辑的开发上。

目前业界较为公认的无服务器架构主要包括两个方面,即提供计算资源的函数服务平台 FaaS,以及提供托管云服务的后端服务 BaaS。

  • 函数即服务(Function as a Service):是一项基于事件驱动的函数托管计算服务。通过函数服务,开发者只需要编写业务函数代码并设置运行的条件,无需配置和管理服务器等基础设施,函数代码运行在无状态的容器中,由事件触发且短暂易失,并完全由第三方管理,基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行,并且按实际执行资源计费,不执行不产生费用。

  • 后端即服务(Backend as a Service):BaaS 覆盖了应用可能依赖的所有第三方服务,如云数据库、身份验证、对象存储等服务,开发人员通过 API 和由 BaaS 服务商提供的 SDK,能够集成所需的所有后端功能,而无需构建后端应用,更不必管理虚拟机或容器等基础设施,就能保证应用的正常运行。

云原生是分布式应用当下重要的发展路径,其终态应当是 Distributionless,所有与分布式相关的问题由云平台解,分布式应用的开发会跟传统应用的开发一样方便,甚至更加便捷。

链接