前面我们了解了微服务化的拆分原则,以及从架构师角度如何权衡微服务化的利弊。这一小节我们对微服务架构所要考虑的技术难点做一番探讨。
微服务架构所面临的技术问题 - 图1

蜀道难,难于上青天

微服务架构可不是打嘴炮,它实打实地考验一个公司的综合技术实力,这不仅关乎架构层面的技术选型,团队成员对微服务体系的理解也决定着微服务化在执行层面的深度,而这套架构后面各个组件的线上部署维护也需要强大的运维能力。
所以说,在项目中应用微服务架构可谓是蜀道艰险,青天没上成,可能先去了西天。
架构师是一个很神奇的职业,为什么这么说呢,因为我工作中遇到的架构师,不夸张的说,80%都是PPT架构师,除了会写PPT以外没多大本事。脱离一线过久,代码是写不来了这辈子不会再碰代码的,技术栈跟不上时代发展,架构脱离实际业务,没有落地能力。
微服务架构的落地是要亲身躬行,靠实践经验的积累才能做好的。接下来我们看一看在微服务改造的过程中,需要我们去攻克的技术难点。

一道道的沟沟坎坎

服务治理和负载均衡

微服务架构广泛应用在超高并发系统中,中后台服务集群的规模着实不小。就拿淘系的下单接口来说,一个下单指令要调用近二十个后台微服务协同完成任务(可能现在更多了),而在双11这类业务场景下,核心链路的一个微服务背后的虚机数量都有近万台。
因此,服务与服务之间的调用,就成了微服务架构需要解决的第一个问题。与此同时,大规模集群中虚机的上线下线是每天的日常任务,集群的扩容缩容也很常见,我们的微服务架构需要探知到集群中各个服务节点的状态变化,这样就知道哪些节点是可以正常提供服务的。我们管这个领域叫做服务治理
与服务治理搭档的还有负载均衡,面对茫茫多的服务器,如何将海量用户请求分发到不同的机器。考虑到有的机器性能比较弱,或者机房带宽不大,网络响应慢,如何根据实际情况动态地分发服务请求?这个领域就是负载均衡需要解决的事情。

服务容错

地盘大了难免杂事不断,集群中难免有那么几台机器跑着跑着就慷慨就义了。那么对于其它的服务调用者来说,如果不巧正好调用到了这些挂掉的机器,那自然会获得到失败的Response。面对这种情况,后台服务可有另一条路走?
在高并发场景下,有的服务会承担较大的访问请求,这有可能导致响应时间过慢,甚至会响应超时。那调用方在超时后经常会发起重试,这样会进一步增加下游应用的访问压力,进而导致一个恶性循环。那么面对这种情况,我们有解决方案吗?
以上就是微服务领域中降级和熔断技术需要解决的问题,我们管这些叫做服务容错。

配置管理

大家平时在项目中都怎么管理配置项呢?使用配置文件?如果我有一个业务场景,需要随时调整配置,这种配置文件的管理方式可能就玩不转了,我们总不能每次改配置的时候都要重启机器吧。
那么把配置项存到数据库里?可以倒是可以,但是访问量增加的时候也会将压力传导到数据库,数据库往往是比较弱不禁风的一环,很可能被压垮。那么放到缓存里?这一定程度上解决了性能问题,不过在某些业务场景下还是不好用,比如我希望给不同服务器配置不同属性值,指定name属性在某100台机器中的值是张三,在剩余机器中的值是李四。
以上问题在微服务领域也不是什么大问题,服务配置管理就是专门解决这类问题的利器。

服务网关

我们的系统对外提供的网络访问入口只有一个,这通常就是一个域名网址。但是这套系统后面的服务器可有千千万,那么在微服务架构下,是如何将用户请求转发到每个不同的服务器上的呢?这就是服务网关需要解决的事情。
前面我们学习过Nginx网关,大家也应该了解了网关的含义,不过在微服务领域里,网关层会更加智能一些,它会感知服务器上下线的变化。欲知微服务网关如何与服务治理搭配使用,且听下回分解。

调用链路追踪

前面提到一个淘系下单场景会调用一连串的微服务,我们YY这么一个线上故障,有个用户买了两只大猪蹄子,结果东西送到家变成了两只鸡爪子。店小二说没发错货啊不信自己看订单,打开一看还真是,下单的时候选的猪蹄子,下单以后就成了鸡爪子。
上面这个问题出在整个下单链路哪个环节呢?是订单中心搞错了商品ID,还是购物车页面传了错误ID给订单系统,或者说搜索页面一键下单功能没取到正确的ID?迷雾迷雾在迷雾,怎么拨开迷雾见真相?
调用链追踪,从前到后整个调用链路全景数据展现,用事实说话,从此甩锅更加精准!

消息驱动

消息驱动是老朋友了,相信大家在项目中也经常使用消息中间件。我们试想这样一个场景,双11当天24点0分0秒一过,数万万的败家亲们一拥而上,下单接口调用量飙升,就快到了崩溃边缘。那我们后台的订单服务如何才能顶住这一波波攻势?亲,消息驱动组件加上限流组件来做削峰填谷了解一下?
不仅如此,微服务各个系统之间的解耦也可以用消息组件来实现。其实消息驱动在微服务里的实现也就是多做了几层抽象,调用起来更加方便,个中滋味还请同学们亲身体验。

限流

再厉害的系统也有性能瓶颈,强如阿里打造的双十一也抵不住全国剁手族齐上阵,限流是最经济高效,在源头处消减系统压力的手段。微服务的后台服务节点数量庞大,单机版限流远不能解决问题,我们需要在服务器集群这个范围内引入分布式限流手段。

小结

这一节跟大家介绍了微服务架构中的技术难点,在后面的章节里,我们将使用Spring Cloud的十八般兵器,挨个解锁上面的问题。