RPC架构之SOA服务化架构学习(一)
传统垂直应用架构
背景：传统垂直MVC项目简单分为展示层.业务逻辑层.数据访问层
-
缺点:如1.复杂应用的开发维护成本变高，部署效率逐渐降低
2.团队协作效率差，部分公共功能重复开发，代码重复率居高不下
3.系统可靠性变差。随着业务的发展，访问量逐渐攀升，网络流量、负载均衡、数据库连接等都面临着巨大的压力. - 走向：当垂直引用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。同时将公共能力API抽取出来，作为独立的公共服务供其他调用者消费，以实现服务的共享和重用，降低开发和运维成本。应用拆分之后会按照模块独立部署，接口调用由本地API演进成跨进程的远程方法调用，此时RPC框架应运而生
具体可参考《分布式服务框架原理与实践》
集群管理,负载均衡
负载均衡有F5硬件负载均衡和软负载均衡.
- 这里我简单讲下软负载均衡，nginx的反向代理服务很好的实现了集群管理,负载均衡.反向代理就是根据客户端的请求，从其关系的一组或多组后端服务器上获取资源，然后再将这些资源返回给客户端，客户端只会得知反向代理的IP地址，而不知道在代理服务器后面的服务器簇的存在.
session失效：
nginx默认算法是轮询服务器,这有一个问题session会失效
- 解决办法1：upstream里设置ip_hash即采用哈希算法则可以解决这个问题，某个用户请求了A服务器,接下来该用户只会请求A服务器，除非A挂了，则会请求转入别的服务器，这时候还是会存在session失效的问题.
- 解决办法2:session共享,比如2个tomcat来说,session共享需要发生网络通信也就是会建立连接，如果集群有多个，多个请求同时到每个不同tomcat，比如100个请求到100个不同tomcat，则会把100个的session共享到另外99个tomcat，则此时连接就100了，集群越多性能反而大大降低了.
因此nginx自身session共享不建议，轮询算法中可通过别的方法，如redis共享session.
初步学习分布式，理解较为浅，后续还会改动~~~
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
