一点一点理解微服务

架构 专栏收录该内容
10 篇文章 0 订阅

架构演进小史

随着用户数量的增加,我们的项目在一个 Tomcat 容器、一个 MySQL 数据库上倍感吃力,用户抱怨访问响应速度慢,我们在服务器上观察 CPU 占有率飙高,可用内存不足等问题。这种集中式结构如下插图所示,也可称为“单机或单体结构(Monolith)”。

在这里插入图片描述

用户量上去了当然是好事,对于我们技术人员却是挑战更大了。首先我们可以想到一些简单直接的方法,就是升级带宽、升级服务器硬件配置等——不错,除了这些横向的方法外,还有纵向维度的方法,而且这是与软件深度结合的,并不是简单地修改硬性配置那么简单。

最开始 Web 服务器、数据库、文件资源是在同一台机器上跑的,一个服务器的处理能力是有限的,先将它们分离:Web 服务器独立一台机器、数据库独立一台机器、文件存储独立一台机器——显然,静态资源的文件如图片、视频等不需要动态处理,那么采用 Apache 或 Nginx 即可,无须 Tomcat,或者部署在阿里云 OSS 专门优化文件的存储,甚至加入网络优化的 CDN 机制。

这种结构可称为分布式(Distributed)结构如图2所示,当然现在的这种做法是比较粗浅地按照软件形态来划分。

在这里插入图片描述

与此同时,Web 程序加入各种缓存服务,例如 JSP 动态页面静态化,那也是一种缓存策略,当然还有专门用于缓存的 Redis 或 Memcache 的服务。

数据库当然也是与 Web 服务器分离。如果发现性能瓶颈在数据库,采取主从数据库(Master/Slave)、读写分离和分库分表等的策略。与此同时还要不断进行优化 SQL,加入索引等工作。此阶段最后形成如插图所示的具体架构。

在这里插入图片描述
用户量达到一定数量级之后,发现上述优化的招数都不灵了,该如何是好?上述是一台机器做一件事情,光一台机器做不来,就要多台机器去支撑它了,故所以还是堆机器,但是策略明显不同。这种方式我们称为“集群结构(Cluster)”,如插图所示。
在这里插入图片描述

原先单机运行的服务,无论是Web服务器还是数据库服务器,把它作为节点(Node)复制多份副本,构成了一个集群,是一种组件的多个实例。比如说同时有 100 个请求过来,后端准备好有10台 Web 服务器,则平均分给每台 10 个请求去处理。可见这有一关键角色负责调度这些节点如何响应请求的,称为“负载均衡服务器”,用户的所有请求都先交给它,然后根据负载情况落实分配。通过一定的算法,让空闲的节点(负载较小)优先响应,故障的节点则不参与工作。

机器多的好处还不止于性能的改进,还使得容灾能力变为可能,一台机器挂了就挂了,集群机器允许部分机器挂了整个系统还是可用的。

请体会分布式(如插图 7.2)与集群(如插图 7.4)的微妙不同,分布式任务之所以区分 A、B、C……表示拆分过的不同业务,例如商城一个下单业务可分为下单初始化业务、支付业务、财务业务、物流业务等;集群的任务没有区分 A、B、C……是表示任务是一种整体业务,未经拆分且相互隔离,复制在多个服务器上执行。也就是说,集群下的任务仍是单机性质的应用,包含了多个业务能力,且没有与其他节点进行通信,任务自始至终都在单个节点中的进程完成。

集群与分布式两者并不冲突,实际中它们往往配合一起使用。

当业务增长到一定程度的时候,发现上述优化的招数都不灵了,又该如何是好?尽管集群结构的好处就是系统水平扩展非常容易,但不得不说堆砌机器的成本非常高。况且这一问题并不是线性的,比如说电商场景的秒杀促销活动:碍于单机应用的整合,“秒杀”都是部署在一个 WAR 包里面的,那样的话,当大量请求高速涌入时,无法识别哪些是秒杀流量,哪是是正常页面的流量,很可能因为促销活动影响了正常网络的访问。考虑这种情况,不得不把系统内部放进更细化的颗粒度去思考了,具体说,就是必须单独对一个模块进行扩展,而不是作为一个整体里“笼统地”扩展(尽管已经集群了)。渐渐地形成了一种“业务拆分”的技术手段,把一些业务逻辑使用独立的进程来承载,可以更细化地进行扩容,伸缩性更强。像这种以单个业务为视角的可为理解为分布式的进一步深化应用。

分布式下的任务可视作一个服务(Service),每个服务器节点都是只完成这一种服务的,专注性更强。这不仅是性能优化之下带来的要求,同时还是架构上合理化的迫切需求。试想想看,一个系统有论坛有邮箱有聊天室,涉及了用户登录和用户中心,由于分开部署都各自一套,不仅资源重复浪费而且管理起来也不轻松。于是为克服上述问题,分布式服务化等的各种思想和方法论在大型项目中被引入进来了。

微服务风格架构

深度分布式架构下的特征是业务拆分(服务拆分),形成一个比集群网联系更强、更密切的网络。以往我们在学习工作的环境都是把所有代码放在一个项目中,部署时打包WAR包上传到服务器中,这种就是单机结构。即使进化到集群结构,实际工作是多部署几台服务器但代码基本相同的,无须作太大的修改。但是当进入到当下这个分布式的结构之后,旧的代码可是要根据几个独立进程之间的通信问题作出修改。

假设仍是商城的例子,按照微服务的思想,我们需要按照功能模块拆分成多个独立的服务,如:用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。每个服务可以自己独立的 Web 容器或数据库,甚至这些服务可以是异种语言编写的(如 Java/PHP/Go/Node.js 等)。

在过去的单机结构中,一个模块调用另外一个模块,简单自如得像一个函数呼叫另外一个函数,不违和不做作,很少进行跨进程的调用,也根本不存在微服务才有的服务注册、发现。但经过业务拆分的服务化改造后,考虑的问题更多了,分布式网络拓扑结构、网络可靠性、通信机制等内容成为了我们关注的话题。不可避免地,各服务之间需要一种相互通信机制来沟通,这便是 RPC(Remote Procedure Call)调用了。

微服务的好处是:告别强耦合、混沌、笼统的大系统,化解为一个个“微小的服务”,能够有针对性的对某一模块进行扩展和维护,例如上述商城那例子,下订单模块和秒杀模块在促销前提升节点数量就可以了,而后台系统维持原有能力即可;另外因为解耦了、抽取了所以各模块变得可轻松替换了。微服务而外的好处是随结构带来的模块复用,这点很好理解,如同拆分了独立的函数,即可实现代码复用。这一点并非性能上的使然,而是业务服务化之后梳理带来的好处。

为了解决集群不能解决的问题于是提出了分布式的微服务。而微服务大体来说没有什么银弹级别的灵丹妙药,仍是“分而治之(Divide and Rule)”的哲学。另外一面来说,为了解决一个问题却引入了更多的问题要去克服。是否值得呢?一旦微服务改造或实施不成功,往往就不是“化繁为简”而是“简单的事情变复杂化”了,得不偿失。这不是逻辑上的悖论,还是那条恒古不变的金科玉律:总之视乎需求取舍而定,当集群实在满足不了,才上微服务。

提到微服务不得不提十几年前就有的 SOA(Service -Oriented Architecture),微服务与之有许多重叠的概念,但 SOA 的缺点是如 ESB(服务总线)和 WebService 子类的包袱比较重。微服务,顾名思义,其特点在于“微小的”各个子服务构成了一个大的系统,相对轻量级很多。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值