共计 888 个字符，预计需要花费 3 分钟才能阅读完成。
传统垂直应用架构
背景：传统垂直 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.
初步学习分布式，理解较为浅，后续还会改动~~~
