ToB企服应用市场:ToB评测及商务社交产业平台

标题: 微服务架构演进 [打印本页]

作者: 曹旭辉    时间: 2022-6-24 23:00
标题: 微服务架构演进
本文主要介绍微服务架构是如何演进而来。微服务架构从单体架构演进而来。在单体应用相对较小时,应用的开发、测试和部署相对简单,但随着时间的推移,更多的功能被添加到应用中,代码的规模也进一步增长。作为功能扩展的结果,单体应用很快陷入单体地狱。开发变得缓慢和困难,因为系统本身过于庞大和复杂,以至于任何一个开发者都很难理解它的全部。这种复杂性逐渐形成一个恶性循环:由于代码库太难于理解,因此开发人员在更改时更容易戳错,且每一次更改都会让代码库变得更复杂、更难懂。针对大型复杂单体应用的开发,越来越的共识趋向于使用微服务架构。本文将从架构角度介绍微服务架构从单体架构的演进过程。
单体架构

任何一个复杂架构都是从简单架构演进而来,微服务架构从单体架构演进而来,这里介绍下经典的单体架构。一个经典的单体架构的部署图如下:

在单体架构中,应用服务和数据服务分离。这是一种经典的存算分离模式的应用,这样做的好处是,不同特性的服务承担不同的角色,处理能力和存储空间得到极大改善。单体架构中,还引入缓存改善服务的读写性能。同时,为了加速服务的访问速度,引入CDN和反向代理技术。这两个中间件的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求数据时,可以从物理距离最近的网络提供商机房获取数据,而反向代理服务则部署在网站的中心机房,当用户请求中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存用户请求的资源,则直接将其返回给用户。此外,服务使用横向扩展的方式,来解决高并发问题,从而实现系统的可伸缩性。通过负载均衡服务器,可将外部请求路由(分发)到任一应用实例。
需要说明的是,经典单体架构图中除了应用服务器是必需,其他组件都不是必需的。技术是为业务而存在的,应根据业务需要合理的选择技术。如,业务不提供文件服务能力,则不需要文件服务器,业务不提供客户端访问入口,则不需要CDN、反向代理服务器等。
分布式架构

单体应用随着时间的推移和反复的迭代开发,往往会进化成一个大泥球结构。在这种结构下,各个模块关系繁杂且牵一发而动全身,严重影响应用的可维护性、可扩展性和可测试性。针对日益庞杂的单体应用,应用的垂直拆分是一种必然选择。而应用拆分之后,则从单体架构演变成分布式架构。一个经典的分布式架构的部署图如下:

为了应对日益复杂的业务场景,根据业务场景拆分整个应用是一种合理的选择。这样,整个业务分成不同的产品线,如交易系统可将首页、卖家、卖家、订单等拆分成不同的产品线,分归不同的业务团队负责。拆分后,每个产品线维护的应用独立部署维护,各子应用之间通过消息队列等进行数据通信。随着业务拆分越来越小,存储系统越来越庞大。为避免所有应用都和数据库连接,导致数据库连接池资源不足,针对可复用的业务连接数据库,提供公用业务服务。针对其他公共业务,也抽取相关服务。如认证鉴权服务、NoSQL数据库读写服务、缓存读写服务等等。
SOA

在分布式架构的演进中,SOA(Service Oriented Architecture,面向服务的架构)获得一部分技术厂商的青睐。SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。 SOA 并不是一个新鲜事物,而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务,但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象,所以虽然SOA 是基于对象的,但是作为一个整体,它却不是面向对象的。一个经典的SOA架构的部署图如下:

SOA架构遇到的一个问题是,服务拆分后,如何对外统一提供服务。API Gateway是一种解决策略,API Gateway是外部世界进入应用的入口。它负责请求路由、API组合和身份验证等多项功能。来自外部的所有API请求先转到API Gateway,然后API Gateway再将请求路由到相应的服务。
SOA中的每个服务都包含执行完整的独立业务功能(如用户鉴权、订单、购物车、交易等)所需的代码和数据集成。这些服务接口提供松耦合能力,这意味着,即使基本或根本不知道服务如何在底层集成,也可以调用服务公开的接口。
在SOA架构中使用服务总线连接各服务。ESB(企业服务总线)是一种模式,集中式组件可通过这种模式执行与后端系统的集成,然后将这些集成作为服务接口提供。ESB是一个智能管线,它会转换数据模型、深度连接、路由机制以及组合多个请求,并将它们作为单个服务接口提供,以供新应用程序复用。从理论上讲,开发者可以在不使用 ESB 的情况下实施 SOA,但每个应用程序所有者都必须通过自己独有的方式来公开服务接口,这就需要完成大量工作(即使接口最终可复用也不例外),并且在未来会带来巨大的维护挑战。 实际上,ESB 最终被认为是所有 SOA 实施都包含的事实元素,以致于有时将这两个术语作为同义词使用,从而造成了混乱。
微服务架构

SOA架构可以用来应对臃肿的单体应用,从而提高软件的可复用性,比如身份鉴权等公共能力。SOA的目标是在不影响其他服务的情况下透明地替换一个服务,只要替换之后的服务的外部接口没有太大的变化即可。这种性质大大简化软件维护甚至是软件重写的过程。但是,SOA架构高度集中的 ESB 模式及其相关的集中式集成专家团队可能会成为瓶颈。 而微服务架构会将 ESB 分解为更细粒度的分散式集成。另外,基于SOA架构构建的应用,一般都有一个全局的数据模型,并且共享数据库。而微服务架构中每个服务有属于它自己的数据库。一个经典的微服务架构的部署图如下:

在微服务架构中,服务间使用轻量级的通信管道,也即哑管道,而不是SOA架构中的智能管道(如ESB), 微服务架构强调了服务的重要性。相比SOA,微服务架构中的服务拥有更小的服务尺寸(规模)。SOA善于集成大型、复杂的单体应用程序。微服务家架构中的服务虽然不是必须做到很小,但通常都比较小。因此,SOA应用通常包含和集成若干个大型的服务,而微服务架构的应用则常常由数十甚至上百个更小的服务组成。
总结

应用从单体架构演进成分布式架构,在分布式架构的演进过程中,又出现了SOA和微服务架构。微服务架构优良性,使其越来越多的在云服务厂商中应用。那么微服务架构会是架构演进的终点吗?答案是否定的。早在2014年,亚马逊就提出并应用Serverless架构。当然,相比微服务架构,两者作用层次不同,但本质都是将变化点抽离出来,让开发人员集中关注业务,减少非业务的影响,从而提高生产力。架构演进不是终点,是一个不断进化的事情。
参考

微服务设计 Sam Newman 著, 崔力强 等 译
微服务架构设计模式 Chris Richardson 著, 陈斌 等 译
大型网站技术架构 李智慧 著
http://www.uml.org.cn/soa/202004152.asp?artid=23177 SOA软件架构设计

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!




欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4