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

标签：权限   文章   等等   工作   自身   开发人员   ges   其他   redis   

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

二、服务器集群

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

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

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

集群引入了几个新问题：

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

三、负载均衡

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

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

（集群带来session的处理问题一般可以采用redis或者其他缓存服务器进行处理，这里不展开讨论了）

四、分布式

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

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

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

当然上图的架构还是会存在单点问题，这时候可以和集群的技术相互结合来提高这个架构的稳定性

五、微服务

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

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

写在最后：

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

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

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

标签：权限   文章   等等   工作   自身   开发人员   ges   其他   redis   

原文地址：https://blog.51cto.com/14570694/2477472