微服务框架


目录

文章目录目录微服务架构所面临的问题微服务框架API 网关服务中心熔断、服务降级、限流监控调用链跟踪日志分析配置中心文档中心可信安全Golang 生态的微服务框架Go MicroGO Kit

微服务架构所面临的问题

微服务架构中,服务之间会有错综复杂的依赖关系,例如:一个前端请求一般会依赖于多个后端服务,称为 “1=>N 扇出”。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源(线程,队列等)被耗尽,造成所谓的雪崩效应(Cascading Failure),严重时可致整个网站瘫痪。另外,微服务架构整个应用分散成多个服务,定位故障点非常困难。

微服务组合
微服务框架

微服务依赖:
微服务框架

综上,微服务架构虽然逻辑设计上看是完美的,但就像积木搭建的华丽宫殿一样,经不起风吹草动。主要有两个方面的问题:

    微服务架构整个应用分散成多个服务,定位故障点非常困难。
    微服务数量变多导致其中一个服务出现故障的概率增大,并且一个服务故障可能导致整个系统挂掉,整个系统的稳定性下降。事实上,在大访问量的生产场景下,故障总是会出现的。

为了好好解决这些问题,对故障的处理一般从两方面入手,一方面尽量减少故障发生的概率,另一方面降低故障造成的影响。这些都是微服务框架需要解决的挑战。

微服务框架

微服务框架

一个完整的微服务系统底座的基本功能应该包含:

资源管理:计算、存储、网络资源的管理。
编排:调度、部署和升级。
API 网关:微服务 API 托管、认证和鉴权、负载均衡等。
熔断、服务降级、限流。
监控和告警:监控每个服务的状态,必要时产生告警。
日志和审计:日志的汇总,分类和查询。
调用链跟踪:问题跟踪调试框架。
消息总线:轻量级的 MQ 或 HTTP。
服务中心:服务注册、发现、订阅。

API 网关

API 是服务价值的精华体现。

微服务框架

APIGW 完成前后端分离。
微服务框架

服务中心

服务中心旨在为数量众多的微服务进行注册发布、发现、订阅、负载均衡和健康检查的管理,为微服务之间的交互牵线搭桥。

服务发现服务,提供所有已注册服务的地址信息的服务。各个应用服务在启动时自动将自己注册到服务发现服务上,并且应用服务启动后会实时(定期)从服务发现服务同步各个应用服务的地址列表到本地。服务发现服务也会定期检查应用服务的健康状态,去掉不健康的实例地址。这样新增实例时只需要部署新实例,实例下线时直接关停服务即可,服务发现会自动检查服务实例的增减。

微服务框架

服务发现还会跟客户端负载均衡配合使用。由于应用服务已经同步服务地址列表在本地了,所以访问微服务时,可以自己决定负载策略。甚至可以在服务注册时加入一些元数据(服务版本等信息),客户端负载则根据这些元数据进行流量控制,实现 A/B 测试、蓝绿发布等功能。

服务发现功能有很多组件可以选择,比如:ZooKeeper、Eureka、Consul、ETCD 等。

服务注册:
微服务框架

服务发现:

微服务框架

熔断、服务降级、限流

微服务框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态熔断、服务降级、限流。

熔断:当一个服务因为各种原因停止响应时,调用方通常会等待一段时间,然后超时或者收到错误返回。如果调用链路比较长,可能会导致请求堆积,整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时,应熔断,标记该服务已停止工作,直接返回错误。直至该服务恢复正常后再重新建立连接。

微服务框架

服务降级:当下游服务停止工作后,如果该服务并非核心业务,则上游服务应该降级,以保证核心业务不中断。比如:网上超市下单界面有一个推荐商品凑单的功能,当推荐模块挂了后,下单功能不能一起挂掉,只需要暂时关闭推荐功能即可。

限流:一个服务挂掉后,上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常,很可能因为瞬间网络流量过大又立刻挂掉,在棺材里重复着仰卧起坐。因此服务需要能够自我保护 —— 限流。限流策略有很多,最简单的比如当单位时间内请求数过多时,丢弃多余的请求。另外,也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务,商品服务由于代码问题发起了大量请求,促销服务则只限制来自商品服务的请求,来自订单服务的请求则正常响应。

微服务框架

监控

微服务架构中组件繁多,各个组件所需要监控的指标不同。比如:Redis 缓存一般监控占用内存值、网络流量,数据库监控连接数、磁盘空间,业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的,而且扩展性会很差。一般的做法是让各个组件提供报告自己当前状态的接口(metrics 接口),这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件,定时从这些接口获取并保持组件状态,同时提供查询服务。最后还需要一个 UI,从指标采集器查询各项指标,绘制监控界面或者根据阈值发出告警。

Prometheus 就是微服务架构中指标收集器的标准,而 Grafana 则用于监控界面和邮件告警,这样一套微服务监控系统就搭建起来了。微服务框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。

微服务框架

调用链跟踪

在微服务架构下,一个用户的请求往往涉及多个内部服务调用。为了方便定位问题,需要能够记录每个用户请求时,微服务内部产生了多少服务调用,及其调用关系,这个叫做调用链跟踪。

要实现调用链跟踪,每次服务调用会在 HTTP 的 Headers 中记录至少记录四项数据:

    traceId:标识一个用户请求的调用链路,具有相同 traceId 的调用属于同一条链路。
    spanId:标识一次服务调用的 ID,即链路跟踪的节点 ID。
    parentId:父节点的 spanId。
    requestTime & responseTime:请求时间和响应时间。

微服务框架

另外,还需要调用日志收集与存储的组件,以及展示链路调用的 UI 组件。

微服务框架

以上只是一个极简的说明,关于链路跟踪的理论依据可详见 Google 的 Dapper。

注意,链路跟踪只能定位到哪个服务出现问题,不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。

日志分析

日志分析组件应该在微服务兴起之前就被广泛使用了。即使单体应用架构,当访问数变大、或服务器规模增多时,日志文件的大小会膨胀到难以用文本编辑器进行访问,更糟的是它们分散在多台服务器上面。排查一个问题,需要登录到各台服务器去获取日志文件,一个一个地查找(而且打开、查找都很慢)想要的日志信息。如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。

因此,在应用规模变大时,我们需要一个日志搜索引擎,以便于能准确的找到想要的日志。另外,数据源一侧还需要收集日志的组件和展示结果的 UI 组件。

ELK(Elasticsearch、Logstash 和 Kibana)是目前使用最广泛的日志搜索引擎解决方案:

Elasticsearch:搜索引擎,同时也是日志的存储。
Logstash:日志采集器,它接收日志输入,对日志进行一些预处理,然后输出到 Elasticsearch。
Kibana:UI 组件,通过 Elasticsearch 的 API 查找数据并展示给用户。

微服务框架

配置中心

配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。

文档中心

文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 就是一种流行的 RESTful API 文档方案。

可信安全

因为微服务与微服务之间需要有网络通讯,需要有安全可信的认证。传统做法就是把微服务放到一个可信网络环境中,假设网络环境中所有通讯、执行的应用或微服务都是受信的,它们可以自由通讯或交流,可能有一些轻量级的鉴权与授权进行一定的安全防护措施。

但这个模型会带来一种风险,当有微服务入侵到这个可信网络之中,它会对整个微服务体系造成极大的安全隐患,因为可信网络中的内部防范一定程度上是比较欠缺的。

另外,经常会有可信网络与可信网络之间的微服务互相调用或鉴权的问题,常见解决方法是通过 VPC Peering 或者通过 Gateway 网络的网关打通。利用一个可信通道保证微服务与微服务之间的网络层面可信的调用。但同样引出一种问题,比如在另外一个可信网络中被入侵,便可以攻击到其它相连的可信网络,也增大了受攻击的可能性。

微服务框架

在微服务时代,我们不去假设网络是完全可信的环境。因此,提出了一个叫做微服务或应用可信安全,也就是微服务与微服务或者机密文件之间的每一次通讯,都基于身份体系。微服务会提供给它所沟通、协同的目标对象一个身份认证。就好比我们通过浏览器访问 HTTPS 网站,这些网站需要提供证书,我们的微服务也需要提供一个自身的身份认证,这样接收方就可以通过平台进行认证且查看授权。只有这些认证都通过,才会和开始微服务的通讯。

实际上,利用平台的特点在网络层面内部以应用为中心,又建设起一套基于统一身份认证授权的体系。

微服务框架

但这个体系还是比较难构建的,相当于要在不完全受信的网络中,需要有一个可以信任的平台层或中间层,也就类似 PKI 中的 CA 机制。在 HTTPS 上,比如说我们要信任一个 CA,可能需要提前讲证书预置在操作系统中,从安装时就要预置好,才能提供一个更为安全的端到端的可信,否则是无法构建好这个信任链的。

同样的,在云环境中也需要这个机制。云本身是一个可控平台,通过从云最底层的硬件机制,到云上运行的 OS 上,再到最终向上部署微服务的平台层,我们都要建立起来了一个可证的授信链,最终给每一个微服务提供自身的身份 ID 以及授权可证的授权信息,这样微服务才能提供统一可验证、可证实的身份。也就是说在云原生时代,通过平台思维能够给微服务安全提供更大的价值。

另外在平台与平台之间或网络与网络之间,也可以通过平台级别的可信授信来建立关联的关系,让不同平台之间的微服务也能产生信任关系。为了打通不同的平台,有一个开源项目叫做 Spiffe,它提供了统一的标准身份 ID 以及如何统一标准地进行授权信息的可证和授权信息的认证。

微服务框架

Golang 生态的微服务框架
Go Micro

微服务框架

Go Micro 是一个可插拔的 RPC 框架,提供了以下功能:

服务发现:程序自动注册到服务发现系统。
负载均衡:它提供了客户端负载均衡。
同步通信:提供 Request/Response Transport。
异步通信:具有内置的发布和订阅功能。
消息编码:可以利用 header 中 Content-Type 进行编码和解码
RPC 客户端/服务器端:利用上述功能并提供构建微服务需要的接口。

Go Micro 架构由三层组成:

    服务层。
    C/S 模型层:Serrver 用于编写服务的块组成;而 Client 为我们提供接口,向 Server Model 中编写的服务发出请求。
    第三层有以下类型的插件:

Broker:在异步通信中为 Message Broker(消息代理)提供接口。
Codec:用于加密或解密消息。
Registry:提供服务搜索功能。
Selector:在 Register 上构建了负载均衡。
Transport:是服务与服务之间进行同步 Request/Response 的通信接口。

它还提供了一个名为 Sidecar(边车)的功能。Sidecar 能够集成以 Golang 以外的语言编写的服务。它还为我们提供了 gRPC 编码/解码、服务注册和 HTTP 请求处理。

GO Kit

Go Kit 是一个用于构建微服务的编程工具包。与 Go Micro 定位于框架不同,它的定位是一个库。

Go Kit 提供以下代码包:

Authentication(鉴权):BasicAuth 和 JWT。
Transport(协议):HTTP、gRPC 等。
Logging 日志:服务中的结构化日志接口。
Metrics 度量:CloudWatch、Statsd、Graphite 等。
Tracing 分布式追踪:Zipkin 和 Opentracing。
Service discovery 服务发现:Consul、Etcd、Eureka 等。
Circuit breaker(限流熔断):Hystrix 在 Go 语言的实现。

原创:https://www.panoramacn.com
源码网提供WordPress源码,帝国CMS源码discuz源码,微信小程序,小说源码,杰奇源码,thinkphp源码,ecshop模板源码,微擎模板源码,dede源码,织梦源码等。

专业搭建小说网站,小说程序,杰奇系列,微信小说系列,app系列小说

微服务框架

免责声明,若由于商用引起版权纠纷,一切责任均由使用者承担。

您必须遵守我们的协议,如果您下载了该资源行为将被视为对《免责声明》全部内容的认可-> 联系客服 投诉资源
www.panoramacn.com资源全部来自互联网收集,仅供用于学习和交流,请勿用于商业用途。如有侵权、不妥之处,请联系站长并出示版权证明以便删除。 敬请谅解! 侵权删帖/违法举报/投稿等事物联系邮箱:2640602276@qq.com
未经允许不得转载:书荒源码源码网每日更新网站源码模板! » 微服务框架
关注我们小说电影免费看
关注我们,获取更多的全网素材资源,有趣有料!
120000+人已关注
分享到:
赞(0) 打赏

评论抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

您的打赏就是我分享的动力!

支付宝扫一扫打赏

微信扫一扫打赏