项目架构相关知识的个人简单理解（水平有限，勿喷）

（一）传统架构

                             

      一台Web应用服务器Tomcat并发量为400，如果当并发量为40000时，理论上需要100台；

同一个工程部署到多台服务器上就会存在两个问题：

       问题1: 在Tomcat集群中节点数量不断增加时,集群服务能力不断增加,但当达到一定程度时,集群的服务能力会下降.

       问题2: 此时每个tomcat中都有一个session,例如用户登录时由于存在多个session会致使登录多次,不利于客户体验.

（二）分布式架构：

     把传统架构按照模块拆分成多个子系统，多个子系统相互协作完成总的业务流程。

     优点：

         1. 把模块拆分，使用接口通信，降低模块之间的耦合度。

         2. 把项目拆分成若干个子项目，不同的团队可以负责不同的子项目。

         3. 增加某块功能时只需要再增加一个子项目，调用其他系统的接口即可。

         4. 可以灵活的进行分布式部署,同时可根据实际情况对某一指定子系统增加服务器的部署，此时可以很好的

             解决问题1。

         5. 此时通过session复制,将多个tomcat中的session信息抽取,形成一个独立的子系统或子模块

          （单点登录系统）将抽取的session进行管理，此时可以很好的解决问题2。

    缺点：

        1、系统之间交互需要使用远程通信，接口开发增加工作量。

        2、各个模块有一些通用的业务逻辑无法共用。

由传统架构演变过程简单理解如下：

                     

• 单一应用架构（传统架构）
  • 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
  • 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
• 垂直应用架构
  • 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
  • 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

• 分布式服务架构
  • 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，
  • 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

• 流动计算架构
  • 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
  • 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 

       RPC架构和SOA架构的不同之处关键就在于是否有服务中间件进行统一管理和资源调度。

（三）微服务架构

        SOA注重的是系统集成方面，而微服务关注的是完全分离

        微服务重点强调的一个是"业务需要彻底的组件化和服务化" 

微服务特征：
（1）领域驱动设计（DDD）：作为业务划分的重要指导理论依据。提出“限界上下文”概念，每个上下文可以分成内部和外部两部分，每个上下文都有明确的接口，该接口的定义决定了它会暴露哪些功能给其它上下文。
（2）去中心化：去掉SOA架构中作为中心角色、协调各系统进行功能输出的ESB（企业服务总线）
（3）独立数据库：任何单独的服务都可以独立自治，不受其它系统的制约和调配，而SOA中并没有对这个原则有明确的要求。
（4）基础设施自动化部署

拆分带来的问题
1、数据一致性的解决：
（1）重试机制（支持幂等）
（2）补偿机制
（3）使用柔性事务（TCC）：系统在从A状态到达B状态时必须要先经过C（软状态）
2、服务容错性的解决：
（1）超时机制
（2）隔离机制：采用为每个对下游资源的调用分配最大个数的线程池或者连接池来解决
（3）断路保护机制：把已经尝试过多次的失败请求进行累计，当达到一定值时，忽略对其调用
（4）服务降级机制：当系统出现断路时，通过缓存或静态资源来给用户返回一些非实时数据，让用户无感知
3、系统性能的解决：
（1）考虑使用RPC进行远程通讯
（2）增加缓存使用：尽量把每次对下游系统的请求进行缓存

（四）静态化架构——动静分离

           不考虑并发量，如果一个系统在经过架构优化、系统本身的模块优化、代码优化以及各种缓存优化后，在极端情况下：将数据全部缓存，所有请求结果直接返回，如果查询的QPS（每秒查询率：一台服务器每秒的查询次数）达到上万次，Java系统本身已经达到瓶颈。

           由于Java系统本身弱点，并不擅长处理大梁的链接请求，每个链接消耗的内存较多，同时Servlet容器解析HTTP较慢等（例如：由Jsp解析成Java+html过程比较费时）。在高QPS的情况下应让请求绕过Java系统，在Web服务器层直接返回，从而将动态系统进行静态化架构改造。

           静态化架构特点：

                  1. 页面对应的URL固定，URL能唯一标识一个页面。

                  2. 页面中不包含与浏览者相关的因素，即不能包含JS动态生成的部分（如，用户姓名、Cookie数据等）。

                  3. 页面中也不能包含如时间（服务器端时间）、地域等动态数据。将动态内容JSON化，然后利用Nginx将浏览器的html代理到对应的服务端。

           静态化方案：

                  有以下几个问题：

                   a. 使用ESI or CSI

                       ESI : 在Web代理服务器上做动态内容请求，并将请求插入到静态页面中，使用户看到时便是一个完整页面。

                       CSI: 通过一个异步JS请求单独向服务端获取动态内容。

                  b. 是否使用物理机

                      物理机：相对于虚拟机而言，对实体计算机的称呼，提供给虚拟机以硬件环境。

                  c. 压缩问题：增加一层Cache，必然增加数据传输，那么由谁压缩，以何种方式压缩 便值得考虑。

                  d. 网卡等硬件问题

          方案A： 采用Nginx + Cache +Java结构的虚拟机单机部署

                           

          方案B： 采用Nginx + Cache +Java结构的实体机单机部署

                          

                  优点：使用物理机，较方案A增加硬件环境，并采用一致性Hash分组来提升命中率。

          方案C： 统一Cache层的实体机单机部署

                          

                      优点：较方案B将Cache统一管理，减少运维成本，同时也方便其他系统接入。

          方案D： 将Cache前移到CDN上

                          

                       优点：较方案C将Cache层前移到CDN上，离用户更近，效果会更好，但放到全国所有的CDN节点上现阶段不太可能。

         * 回源：当用户访问某一个URL时，如果被解析到的那个CDN节点没有缓存响应的内容或者缓存已过期就会回源站去获取，如果没有用户访问，该CDN节点不会主动去源站获取。