我们在做一个访问量不大的项目的时候, 一台服务器上面部署一个应用+数据库就够用了…
那么访问量稍微大一点的话,用户就会说卡顿,反应慢 等等各种情况,这个时候呢我们就用集群 架设Nginx 部署多个服务 由Nginx(负载均衡)负责把请求转发到其他服务器上,这样就解决了用户说的反应慢的问题…
过了一段时间之后呢 我们会发现数据库扛不住了,然后各种优化 emmmmmm 最后发现还是很不行, 应用服务好,数据库宕机 ,这个时候就上数据库读写分离,多架设几台数据库服务器,做数据库分库分表,然后你就会发现服务变得很流畅,数据库也不宕机了…
又过了一段时间,公司的业务越做越大,服务器的访问量也变得越来越高,而且都是查询, 吸取之前宕机的教训而且保证数据库的健壮性,我们会加上缓存,把客户频繁访问的数据存入缓存里面,这样就会缩短查询的时间,减少服务器的访问…
在后来,项目越做越大,加了很多的功能,变得很庞大 ,修改一个类就需要全盘上传,切换Nginx重启 发布,这样的结果就是发布的流程越来越长,越来越频繁,于是我们把项目拆分, 用户信息是一个模块,设备信息是一个模块,这样就达到了修改用户信息的时候只需要修改用户模块,修改设备信息的时候只修改设备信息的模块就好了,但是还是需要切换顶层的Nginx,把要重启的服务的流量切到可用的服务上,于是我们就想到了RPC…
那么RPC解决了什么呢? 所有的服务在启动的时候注册到一个注册机里面,然后顶层处理在接收到nginx的请求时,去注册机找一个可用的服务,并调用接口. 这样子呢,在不加新功能的时候,顶层处理服务我们就不需要动了? 那修改了用户信息项目的时候,我们只需要一个个更新用户信息项目的服务群就好了…
这样的话,无论是扩展还是服务的健壮性都妥妥的了…