微服务架构所面临的技术问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了微服务架构所面临的技术问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

服务治理和负载均衡

微服务架构广泛应用在超高并发系统中，中后台服务集群的规模着实不小。就拿淘系的下单接口来说，一个下单指令要调用近二十个后台微服务协同完成任务(可能现在更多了)，而在双11这类业务场景下，核心链路的一个微服务背后的虚机数量都有近万台。

因此，服务与服务之间的调用，就成了微服务架构需要解决的第一个问题。与此同时，大规模集群中虚机的。上线下线是每天的日常任务，集群的扩容缩容也很常见，我们的微服务架构需要探知到集群中各个服务节点的状态变化，这样就知道哪些节点是可以正常提供服务的。我们管这个领域叫做服务治理。

与服务治理搭档的还有负载均衡，面对茫茫多的服务器，如何将海量用户请求分发到不同的机器。考虑到有的机器性能比较弱，或者机房带宽不大，网络响应慢，如何根据实际情况动态地分发服务请求?这个领域就是负载均衡需要解决的事情。

服务容错

地盘大了难免杂事不断，集群中难免有那么几台机器跑着跑着就慷慨就义了。那么对于其它的服务调用者来说，如果不巧正好调用到了这些挂掉的机器，那自然会获得到失败的Response。面对这种情况，后台服务可有另一条路走?

在高并发场景下，有的服务会承担较大的访问请求，这有可能导致响应时间过慢，甚至会响应超时。那调用方在超时后经常会发起重试，这样会进一步增加下游应用的访问压力，进而导致一个恶性循环。那么面对这种情况，我们有解决方案吗?

以上就是微服务领域中降级和熔断技术需要解决的问题，我们管这些叫做服务容错。

配置管理

大家平时在项目中都怎么管理配置项呢?使用配置文件?如果我有一个业务场景，需要随时调整配置，这种配置文件的管理方式可能就玩不转了，我们总不能每次改配置的时候都要重启机器吧。

那么把配置项存到数据库里?可以倒是可以，但是访问量增加的时候也会将压力传导到数据库，数据库往往是比较弱不禁风的一环，很可能被压垮。那么放到缓存里?这一定程度上解决了性能问题，不过在某些业务场景下还是不好用，比如我希望给不同服务器配置不同属性值，指定name属性在某100台机器中的值是张三，在剩余机器中的值是李四。
以上问题在微服务领域也不是什么大问题，服务配置管理就是专门解决这类问题的利器。