技术架构演进中，微服务、负载均衡等如何应对高并发与数据存储挑战？

本文共计2970个文字，预计阅读时间需要12分钟。

1. 鸡蛋不能全放在一个篮子里——单一应用应逐步演变为微服务应用。想象一下，你家楼上的业主张叔在装修，工人不当心，导致你家有个房间漏水了，这时候你怎么办？+ 常规办法都是喊人来修。

1、鸡蛋不能都放在一个篮子里——单体应用演进到微服务应用

想象一下，你家楼上有个业主在装修，施工不当，导致你家里有个卧室漏水了，这个时候你怎么办？

正常人都是喊人来修，然后先临时搬到另外的房间睡觉。而不是在维修人员修卧室的时候，全家搬到酒店里去睡。因为，只是那一个房间漏水，其它房间还是能够正常使用的。

在程序中的体现：

单体应用：

项目所有的模块都打包到一起，然后扔到服务器上部署运行。假如这个项目是一个电商项目，里面有下单模块，派送模块等等。你把这些模块想象成你家的房间，一个模块对应一个房间，现在派送模块对应的房间漏水了，这个时候怎么办？没办法，只能全家出去住了，为啥，因为你所有的模块都打包到一个项目里面去了，一个模块挂了，整个项目都得停下来，等派送模块修好了，再启动项目继续运行。缺点一目了然。

微服务应用：

为了解决单体式应用的不足，微服务的概念横空出世。核心就是“拆”，把一整个项目按模块拆成一个个的小项目，所有拆分的小项目之间进行合作通信形成原先的整体项目。这样有什么好处，当我们的项目在运行的时候，同样派送模块挂了，这时候挂了的只有这一个模块服务，你其它模块的服务还是能后正常运行，用户还是能够正常下单，老板还是正常赚钱。维修人员只需要把派送模块修好之后重新运行起来，然后加进来继续给用户下的单送货。