微服务是一种架构模式,或者我们可以说是一种系统设计模式。它基于面向服务的体系结构。
面向服务的架构(SOA)
基于服务的体系结构是一种设计系统或应用程序的方式,可以将整个系统分为多个小的独立组件,其中每个组件均通过所有组件共享的标准通信协议为彼此提供不同的服务。向其他系统/最终用户提供有用服务的系统。
微服务与SOA应用程序几乎没有什么不同,主要是在资源共享和应用程序大小方面。 SOA尽可能多地关注共享。相比之下,微服务模式将更多的精力集中在共享上。微服务的重点是系统每个组件的个性化,以避免单点故障。 SOA使用单一事件总线类型的结构进行消息传递,其中MSA使用简单的对等消息传递REST协议与其他组件进行通信。
SOA体系结构与微服务体系结构
SOA | MSA |
---|---|
尽可能专注于分享 | 尽可能少分享 |
通用总线种类的通讯通道 | 简单消息协议 |
可以使用多种协议 | 主要使用REST。 HTTP2.0 |
共享数据库 | 每个MS都有自己的数据库 |
更加关注服务可重用性 | 组件松耦合 |
共同治理减少了对团队协作的关注 | 更专注于个人团队协作 |
使用不太受欢迎的容器 | 容器的使用很普遍 |
在微服务体系结构中,系统被划分为最精细的粒度,每个组件仅应具有单一职责,除了这项工作之外,它不应执行其他工作,而应与其他组件进行通信以执行任何其他所需的工作。
对微服务架构的需求
最初,软件系统构建为单个,整体的软件单个单元。这种架构非常僵化。所有系统都分为许多模块,例如,对于TGS网站,它可以是身份验证模块,用户数据模块,商品数据模块,数据库访问模块,安全模块,订阅模块。等等。
它是单个应用程序,如果模块中有任何更改,则管理员必须重新编译该应用程序,重新部署整个应用程序。对所有模块进行所有测试。因此,这是相互依赖的模块的整体架构。我们不能考虑修改任何服务,模块而不考虑其对其他服务的影响。
![[TGS整体应用]](http://static.jnpkwjx.com/wp-content/uploads/2019/05/tgs-monolith-application.png)
图1:TGS Monolith应用
上图描绘了TGS整体设计,这是单个实体,单个软件。如果团队在不同的模块上工作,请完成编码部分,然后等待其他组件准备就绪。只有在每个模块都实现之后,他们才能开始下一步软件开发生命周期。
微服务实际上是非常松散耦合的系统中的所有组件,所有组件都可以一起成长。从TGS的角度来看,每个模块都有一个微服务(REST应用程序),即身份验证服务,用户数据服务,商品数据服务,订阅服务。
所有人都将通过REST协议相互通信。如果我们需要更改任何模块,我们可以更改它以测试该微服务并轻松地将其部署在微服务组件中,此更改的交付时间将比单片应用程序开发少得多。
它们可以单独构建,部署和扩展。
整体与微服务
特征 | 单片 | 微服务 |
---|---|---|
敏捷 | 功能增强,重新部署缓慢 | 快速开发和功能增强,重新部署快速 |
停机时间 | 停机时间更长,因为我们需要重新部署整个应用程序 | 更少的重新部署时间,因为我们只需要重新部署一个组件 |
弹性 | 单点故障可能 | 由于系统由多个组件组成,因此没有单点故障 |
生产率 | 与MSA相比生产率更低 | 多个团队协作提高了生产率 |
微服务样本设计架构
这是TGS应用程序的基本微服务设计。在这里,不同的团队承担着实现单个微服务的任务。一旦完成开发,他们就可以部署微服务,并使用其他微服务模拟器开始测试过程。他们不必等待其他微服务来部署其微服务。每个微服务开发都彼此独立。
![[TGS微服务应用程序]](http://static.jnpkwjx.com/wp-content/uploads/2019/05/tgs-microservice-application.png)
图2:TGS微服务应用程序
- 最终用户向TGS MS发送请求
- TGS MS接收来自最终用户的请求
- TGS MS向Auth MS发送请求以验证客户端
- Auth MS通过与用户数据MS联系来对客户端进行身份验证,并发回响应
- TGS MS向订阅MS发送请求以检查用户的订阅
- 订阅接收响应以发送订阅数据。
- TGS MSA向商品MSA发送请求,以查询该用户的授权商品
- 文章MSA将授权文章发回TGS MSA
- TGS MS向最终用户显示所有允许的文章。
- Analytics MS会跟踪用户的所有活动和重要数据,并且每当TGS MS要求提供有用的指标时,它就会发回适当的分析数据。
如果您喜欢这篇文章,您可能还会喜欢..
![]() |
![]() |
![]() |
![]() |