web应用发展历程

web应用在最近10年已经发生了翻天覆地的变化，web应用的如今已经变得非常的复杂，回顾web应用的发展史，我们也不禁感叹，互联网技术的迭代真实太快了。

在web1.0的时候，一台web服务器就能满足所有的业务场景，那时候也没有海量用户，也没有特别复杂的业务，那时候的web请求模型架构是这样的。

这种架构应用现在已经越来越少，那时候最有代表性的系统就是小公司的办公管理系统，门户网站，MES系统之类的单体WEB应用。因为这类系统所有的业务逻辑都在这个Server端完成，无论是开发、升级、部署都非常简单。

小型网站起步的时候基本都是上述架构起步，没有哪些网站一上来就是负载均衡分布式。然而，一些独角兽网站会在在互联网的浪潮中脱引而出，这些网站会在时间的浪潮中不断的积累新用户，上面的单台web服务器架构开始遇到瓶颈，瓶颈就是无法承载那些新增用户的压力，新增用户产生的流量可能会让这仅有的服务器宕机导致整个业务不可用。

此时新的web请求架构就出现了，既然单台服务器无法承载那个压力，那么是否能将负载均匀的分布到多台服务器上呢？答案是可以的，只用在用户和服务器之间加上一层复杂均衡中间件，中间件可以是硬件级别的，也可以是软件级别的。我们常见的负载均衡软件有Nginx以及它的衍生产物。

这类架构将web服务器横向扩展部署，并通过负载均衡器将用户的请求按一定的策略分发到不同的Web服务器上，来将负载近乎均匀的分布到不同的服务器上，甚至在数据库层面引入了只读副本的概念，写主读从，来强化整个系统的并发读性能。这类应用的依然架构清晰简单，不管用户怎么增加，我只要横向扩展web服务器的数量即可，扛住较高的并发。

然而，我们忽略了一个严重的问题，那就是我们只关注于用户的增长，而忘记了本身业务的复杂度的增长，原本简单的业务逻辑随着用户的激增会衍生出更加复杂，更加细腻的分支业务，比如说，支付宝，最初给用户的逻辑就是一个电子钱包，然而，近年来，支付宝衍生出了许多新的业务，如理财、花呗、借呗等业务，上述2种单体应用架构已无法承载更复杂的业务，如果一味的往原有代码中去加入业务逻辑，那么服务端代码将变成传说中的“屎山”，变的毫无可移植性，并非常有可能引入原系统不存在的问题。

微服务架构出现了，这种架构最近几年非常流行，它在整个中国互联网上也是被吹捧的很厉害。伴随着云时代的到来，Server Less也开始被吹捧，许多较为出色的互联网公司也将自己的网站上云了，之所以叫Server Less并不是因为不再需要服务器了，而是我们不再需要花费较大的精力于服务器的细节，这些细节都被云服务这一层给屏蔽了，更多的是关注业务，做好业务。

扯的有点远，回到主题，微服务架构出现之后，web请求就衍生成了如下这样。

在微服务架构中，业务被细分了，每一个微服务都是一个无状态的实例，都有支撑自身业务的持久层、缓存、文件等基础设施，并且微服务本身可能会通过docker，k8s等容器来进行附属，每个微服务之间都有可能存在错综复杂的逻辑依赖关系，这种复杂的分布式架构给运维带来了前所未有的挑战。

我们如何维护这样错综复杂的关系呢？将服务的调用配死在代码中？NoNoNo！既然服务都拆的这么细了，那么就让服务之间自己来维护自己的依赖关系好了，因此，服务注册和发现的概念出现了，面对这种复杂的关系，我们也可以彻底的解放双手了。

服务注册和发现最主要的两个概念实体就是“服务注册中心”和“服务客户端”，所有的客户端都会往服务注册中心进行注册，注册之后才会提供服务，这个动作称为服务注册；客户端会定期的从服务注册中心去将注册列表查询出来，在自己本地实现客户端的复杂均衡，这个动作称为服务发现。

服务注册和发现并不仅仅用于维护IP列表，更重要的是该机制能够进行服务健康检查，健康检查的方式可以是心跳，也可以是查看http请求状态，也可以是执行一段shell脚本，看执行的结果来标记服务的状态，总之健康检查的方式很多。服务注册和发现让运维工程师彻底解放了双手。

以上就是web架构的发展史了，在此打卡记录。

作者：稳哥很稳 

来源：华为开发者论坛