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.

初步学习分布式，理解较为浅，后续还会改动~~~