一文简述服务器架构的演变过程：集群—分布式—微服务

1、单服务器架构

小猿公司创立初期准备搭建一个电商网站销售公司产品，由于公司创业初期用户量不大并且着急上线，在资金有限的状况下公司购买了一台服务器，将小猿团队开发的网站放到服务器上这便算是正式上线了。

2、服务器集群

项目上线没多久就暴露了不少问题：

• 单点问题（服务器宕机将致使整个系统不可用）
• 处理效率问题，单台服务器能够接收的请求量十分有限，用户量大的状况下响应速度大幅降低，甚至出现内存溢出。

遇到了以上问题就必须对服务架构进行调整了，经过商量小猿团队决定增长服务器数量，这样能够已解决单服务器请求压力过大的问题，同时就算有部分服务器宕机了对外也能正常提供服务。

集群引入了几个新问题：

• 每一个服务器的ip地址不同，如何让用户知道到底要访问哪个？
• session问题，以前用户登陆信息，购物车信息等等都是存在服务器的内存中，服务器集群后如何保证每一个服务器共享session数据。

3、负载均衡

如今须要解决的就是让每一个服务器处理的请求数能竟可能的均衡一些，好比轮循机制。这就是负载均衡。

负载均衡器的主要工做就是接受用户请求，而且根据必定的算法将请求分发给不一样的服务器，架构调整后造成了下图的模式

（集群带来session的处理问题通常能够采用redis或者其余缓存服务器进行处理，这里不展开讨论了）

4、分布式

随着小猿公司的业务愈来愈负载，团队的成员也愈来愈多，系统慢慢变的愈来愈庞大，又带来了一些问题：

• 只是修改了某个业务的一些小功能却须要把整个系统从新发布一次；
• 系统业务复杂，开发人员过多很差管理，开发效率低；
• 没法针对某个特定的业务扩大服务器处的理能力

因而想到了一个解决办法，将系统按照模块划分红各个子系统，每一个子系统有对应的团队负责，各个子系统相互调用完成业务功能。

固然上图的架构仍是会存在单点问题，这时候能够和集群的技术相互结合来提升这个架构的稳定性

5、微服务

系统拆分后每一个小系统都是一个完整独立的业务系统，能够拥有本身独立的一个数据库，每一个小系统也就是一个微服务，对外暴露出自身的API，经过微服务，能够很好的实现扩展，如双十一活动的时候，订单量激增，这时候能够考虑多部署几台交易系统来应对高强度的请求压力，随着系统数量的增长，咱们还须要引入服务治理工具（如：Eureka），由它来管理好每一个服务的健康情况。

固然微服务架构一样会引入许多新的问题须要处理，如分布式事务、调用异常处理、权限验证 等等一系列的问题，这里就先不作扩展了，后续再继续完善补充。

写在最后：

欢迎你们关注个人公众号【风平浪静如码】，海量Java相关文章，学习资料都会在里面更新，整理的资料也会放在里面。

以为写的还不错的就点个赞，加个关注呗！点关注，不迷路，持续更新！！！