分析微服务的发展以及可观测性
发布时间：2022-08-04 16:28:09 所属栏目：云计算 来源：互联网
导读：近年来，云原生频繁出现在人们的视野中。随着云原生成为下一代云计算的技术内核，业界正在从关注云原生概念转变到关注云原生落地实践。云原生技术发展势不可挡，依然会是未来云计算领域的热门话题。 01微服务架构演进历史 在真正进入微服务可观测性这个话题
|
近年来，“云原生”频繁出现在人们的视野中。随着云原生成为下一代云计算的技术“内核”，业界正在从关注“云原生概念”转变到关注“云原生落地实践”。云原生技术发展势不可挡，依然会是未来云计算领域的热门话题。 01微服务架构演进历史 在真正进入微服务可观测性这个话题之前，我们有必要了解下微服务架构的演进历史。从整体上看，整体架构的演变过程大致经历了单体应用架构、垂直应用架构、分布式SOA架构、微服务架构的演变。我们以一个电商系统举例(以下图片均来自网上)，主要比较下各个架构之间在运维方面的区别。 举例的电商系统大致分为三个主体模块：主体业务模块(用户管理、商品管理、订单管理)、内容管理模块(CMS管理)、系统管理模块(后台管理)。 垂直应用架构 相比较于单体应用架构，我们对整体系统进行了拆分，优点是可以根据实际情况对某个子系统进行水平扩展，一个系统发生故障可以避免对其他系统产生影响。缺点是拆分后系统比较独立无法相互调用(不同于微服务，只是独立拆分)也导致了重复业务的开发，如图中箭头所示的订单管理、商品管理、用户管理部分，后期维护成本较高。运维方面，难度提升的地方主要在于日志的管理和问题发生点的增加，例如一个问题的发生可能同时由CMS和后台管理系统导致，需要同时解决两个系统的故障。但业务规模的扩大，会导致重复代码和重复修复工作的激增，我们需要将该部分的逻辑进行抽取，继而慢慢过渡到分布式SOA架构。 作为微服务架构的雏形，在解决了水平扩展问题的同时，注册中心的加入既解决了服务之间的注册发现和调用，也使公共模块和逻辑服务得到了抽取独立。但同时也开始让运维监测压力有了比较大的增加，性能和告警关注的服务变多，同时还需要关注注册中心的健康，日志分布更加散乱，业务发生故障时，排查链路变得冗长，对于复杂业务问题我们通常需要同时获取从展示层、注册中心到服务层的日志，并分析其关系才能比较好的定位出问题，这无论对运维还是应用性能提升都是一个挑战。并且服务之间的依赖与调用关系复杂，服务提供方与调用方接口耦合，业务切分不够细的问题也让微服务架构登上舞台。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读
浙公网安备 33038102330482号