畅聊微服务的发展以及可观测性
发布时间：2022-07-04 14:09:42 所属栏目：云计算 来源：互联网
导读：近年来，云原生频繁出现在人们的视野中。随着云原生成为下一代云计算的技术内核，业界正在从关注云原生概念转变到关注云原生落地实践。云原生技术发展势不可挡，依然会是未来云计算领域的热门话题。 在真正进入微服务可观测性这个话题之前，我们有必要了解下
|
近年来，“云原生”频繁出现在人们的视野中。随着云原生成为下一代云计算的技术“内核”，业界正在从关注“云原生概念”转变到关注“云原生落地实践”。云原生技术发展势不可挡，依然会是未来云计算领域的热门话题。 在真正进入微服务可观测性这个话题之前，我们有必要了解下微服务架构的演进历史。从整体上看，整体架构的演变过程大致经历了单体应用架构、垂直应用架构、分布式SOA架构、微服务架构的演变。我们以一个电商系统举例(以下图片均来自网上)，主要比较下各个架构之间在运维方面的区别。 举例的电商系统大致分为三个主体模块：主体业务模块(用户管理、商品管理、订单管理)、内容管理模块(CMS管理)、系统管理模块(后台管理)。 单体应用架构 如图所示，单体应用架构把所有模块都揉进了一个应用内，所有模块均耦合在一起。系统的健康状况通常“所见即所得”(整体功能可用便表示应用处于健康状态)，监测和告警指标通常由JVM的一些参数进行反馈，应用日志产生和收集比较统一集中，排查问题的链路通常比较短(大多问题可由日志直接定位到应用内的某行代码进而分析原因)，维护和监控起来难度不大。但通常一个子模块的问题会导致整体项目出现不可用，无法水平扩展，过于臃肿无法适配大型项目和应用。之后便逐渐演变为垂直应用架构。 垂直应用架构 相比较于单体应用架构，我们对整体系统进行了拆分，优点是可以根据实际情况对某个子系统进行水平扩展，一个系统发生故障可以避免对其他系统产生影响。缺点是拆分后系统比较独立无法相互调用(不同于微服务，只是独立拆分)也导致了重复业务的开发，如图中箭头所示的订单管理、商品管理、用户管理部分，后期维护成本较高。运维方面，难度提升的地方主要在于日志的管理和问题发生点的增加，例如一个问题的发生可能同时由CMS和后台管理系统导致，需要同时解决两个系统的故障。但业务规模的扩大，会导致重复代码和重复修复工作的激增，我们需要将该部分的逻辑进行抽取，继而慢慢过渡到分布式SOA架构。 分布式SOA架构 分布式SOA架构也可认为是微服务架构的雏形，其中展示层对应我们通常所说的消费者或者Controller层，负责控制页面操作需要调用服务层的哪些服务(例如：下单操作使用到用户、订单、商品三个服务，而这三个服务又是抽象在服务层独立存在的)，而服务层是具体的业务逻辑实现供表现层调用，上图的服务层模块应该包括用户管理、商品管理、订单管理、CMS管理、后台管理等所有模块，并且基于SOA的分布式通常还会包含一个注册中心(例如：图中的ESB总线或者类似DUBBO这样的框架)。 微服务架构 现在我们所属的微服务架构通常由一个网关以及各个功能独立的微小服务构成，服务之间的可以相互调用，它们的可用性可由容器和容器编排的能力提供。服务划分的更细、职责更加明确，服务之间可使用RPC、REST进行相互调用，同时为前端提供HTTP接口。 由于服务的彻底拆分，服务的开发可以分发给各个小团队进行独立开发、部署和升级。并且每个微服务可以根据业务实际运行情况进行水平扩容，但同时微服务过多，服务治理成本变得更高，同时还要考虑分布式事务、容错等技术。从运维方面看，服务日志变得更加分散，怎么对全局的微服务进行监控和告警难度更大了，最后出现业务问题进行排查时，链路变得非常冗长，若没有一个全局追踪id，只通过日志的时间戳，无论是业务性能优化还是故障排除都会变得十分困难。即业界不断在讨论研究的问题，微服务的可观测性。  （编辑：开发网_开封站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330459号