本章将会概要性地介绍微服务架构:
分布式云平台的应用环境使得微服务代替单体应用成为互联网大型系统的架构选择
传统的单体应用
Web应用程序发展的早期,大部分Web工程是将所有的功能模块打包到一起部署和运行
单体应用的实现架构类似:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F9YHy0bd-1603527978635)(08115EB291E147E19AF31EAE622249B8)]
采用分层架构,按照调用顺序,从上到下为表示层、业务层、数据访问( DAO)层、 DB 层
在单体应用中,所有这些模块都集成在一起,这样的系统架构就叫做单体应用架构,或称为巨石型应用架构
中小型项目中使用单体应用架构,能体现出其优势
单体应用的整体性能主要依赖硬件资源和逻辑代码实现
优点:
集成非常简洁
易于调试
开发和部署都很简单
可以轻松实现应用扩展
主要有如下不足:
面向服务的架构
Gartner于20世纪90年代中期提出的
核心主体是服务,其目标是通过服务的流程化来实现业务的灵活性
以上两点称之为SOA治理
完整的SOA架构由五大部分组成:基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等
接口采用中立的方式进行定义,它应该独立于实现服务的硬件平台、操作系统和编程语言
目的是要将紧捐合的系统,划分为面向业务的、 粗粒度、松搞合、无状态的服务
服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构的系统
基于这些基础的服务,可以将业务过程用类似 BPEL (业务流程执 行语言)流程的方式编排起来, BPEL 反映的是业务处理的过程
企业还需要一些服务治理的工具, 比如服务注册库、监控管理等
最早是由 Martin Fowler与James Lewis于2014年共同提出
了解细节的读者可以阅览 https://martinfowler.com/articles/microservices.html
根据其描述,微服务的定义可以概括如下:
微服务架构是一种使用 一系列粒度较小的服务来开发单个应用的方式;每个服务运行在自己的进程中;服务间采用轻量级的方式进行通信(通常是 HTTPAPI);这些服务是基于业务逻辑和范围,通过自动化部署的机制来独立部署的,并且服务的集中管理应该是最低限度的,即每个服务可以采 用不同的编程语言编写,使用不同的数据存储技术
其中一些常用的组件及其概念如下:
首先, 通过将巨大单体式应用分解为多个服务的方法解决了复杂性问题
单个服务变得很容易开发、理解和维护
其次,微服务架构模式使得团队并行开发得以推进,每个服务都可以由专门开发团队来开发
不同团队的开发者可以自由选择开发技术,提供 API 服务
再次,微服务架构模式中每个微服务独立都是部署的
理想情况下,开发者不需要协 调其他服务部署对本服务的影响
可以加快部署速度
最后,微服务架构模式使得每个服务易于独立扩展
在实践中也会呈现出其复杂性,具体如下 :
常见的微服务架构方案有四种,分别是 ZeroC IceGrid、 基于消息队列、Docker Swarm和 Spring Cloud
基于RPC框架Ice发展而来的一种微服务架构
Ice不仅仅是一个 RPC 框架,它还为网络应用程序提供了一些补充服务
Ice是一个全面的 RPC 框架, 支持 C++、C#、Java JavaScript、Python等语言
IceGrid具有定位、部署和管理 Ice服务器的功能, 具有良好的性能与分布式能力
下面具体介绍 IceGrid 的功能:
Ice Grid 当前最新的版本为3.7.1 ,在3.6版本之后增加了容器化的运行方式
当前国内选用这种 微服务架构方案的公司非常少
流行时间并不是很久
所谓通信轻量级,是指通信协议与语言无关、 与平台无关
微服务之间的通信方式有两种:同步和异步
同步方式有RPC,REST等;
微服务之间采用发布消息与监听消息的方式来实现服务之间的交互
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NVqdwXfP-1603527978648)(6185568E073543E0A7976607CC022314)]
基于消息队列的微服务架构是全异步通信模式的一种设计,各个组件之间没有直接的捐合关系,也不存在服务接口与服务调用的说法
案例并不多
成本较高且风险较大
需要项目组自己从零开始去设计实现一个微服务架构基础平台
用来提供容器集群服务
目的是 更好地帮助用户管理多个Docker Engine,方便用户使用
通过把多个 Docker Engine 聚集在一起,形成一个大的Docker Engine,对外提供容器的集群服务
同时这个集群对外提供Swarm API,用户可以像使用 Docker Engine 一样使用 Docker 集群
Docker 三剑客包括: Machine、 Compose 和 Swarm
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6H98MimD-1603527978650)(B5A59AA43BE948AC91E85EE11AC4F034)]
通过 Machine可以在不同云平台上创建包含 docker-engine 的主机
Machine通过driver机制,支持多个平台 的 docker-engine 环境的部署
Swarm 将每一个主机上的 docker-engine 管理起来,对外提供容器集群服务
Compose 项目主要用来提供基于容器的应用的编排
用户通过 yaml 文件描 述由多个容器组成的应用,然后由Compose解析yaml文件,调用DockerAPI ,在Swarm集群上创建对应的容器
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wvv69fGM-1603527978652)(7DD6EC57820A4BAEA1CD4442D4FE9033)]
看到-个 Swarm 集群中有两种角色的节点:
一个基于Spring Boot实现的云应用开发工具
是一系列框架的集合
以下为 Spring Cloud 的核心功能:
还有很多基础的功能没有列出,每个功能对应SpringCloud中的一个组件,包括SpringCloudConfig、SpringCloudNetflix(Eureka、Hystrix、Zuul、Archaius …)、 Spring Cloud Bus 等组件
CNCF,即云原生计算基金会
2015年由谷歌牵头 成立,基金会成员目前已有一百多个企业与机构,包括亚马逊、微软、思科等巨头
目前CNCF所托管的应用已达 14 个,知名的项目有 Kubernetes、 Prometheus、 Envoy 等
三大特征,概括如下:
云原生由微服务架构、 DevOps 和以容器为代表的敏捷基础架构组成
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dBfCxnSu-1603527978654)(B16EE790B9904E918A46C5E6C501BD1F)]
12 原则( 12-Factors)经常直译为 12 要素
12 原则由公有云 PaaS 的先驱Heroku于2012年提出(https://12factor.nct/),目的是告诉开发者如何利用云平台提供的便利来开发更 具可靠性和扩展性、更加易于维护的云原生应用
12 原则包括:
另外还有补充的三点: API 声明管理、认证和授权、 监控与告警
已经不那么跟得上时代,也有人批 评 12 原则的提出从一开始就有过于依赖 Heroku 自身特性的倾向
Docker 是一个开源引擎,可以轻松地为任何应用创建一个轻量级的、 可移植的、自给自足的容器
Docker 根本的想法是创建软件程序可移植的轻量容器,让其可以在任何安装了 Docker 的机器上运 行, 而不用关心底层操作系统
Docker 可以解决虚拟机能够解决的问题,同时也能够解决虚拟机由于资源要求过高而无法解决的问题
其优势包括:
最常见的编排框架有 Kubernetes、 Mesos、 Docker Swarm
DevOps 是软件开发人员( Dev)和 IT 运维技术人员( Ops)之间的合作
目标是自动执行软件交付和基础架构更改流程,使得构建 、测试、发布软件能够更加地快捷和可靠
创造了一种文化和环境,可在其中快速、频繁且更可靠地构建、 测试和发布软件
将单体业务系统分解为多个可独立部署的服务
微服务架构有以下优势: