架构设计【可扩展】

一、简介

       可扩展即是通过增加相应的机器来达到抗住系统的突然流量激增的目的。

二、设计方案

        2.1、存储扩展

       比如订单系统，首先针对数据存储，按照基础业务进行拆分的，大体拆为用户库、运营库、权益库、基础数据库、订单库等，具体的酒店这些基础数据就放在基础数据库中，这样拆分还有个好处就是确保了故障的隔离，其中一个挂了不会影响其他的数据，由于业务的高速发展，我们这种基于业务的拆分已经到了部分库的单机瓶颈了，所以，此时要基于数据本身进行扩展，这里假如我们订单库达到瓶颈了，我们可以考虑增加订单库节点来扩展，但是存储层的扩展不能简单的增加节点，而是要考虑长远，一次性分配多个节点点来达到后面的扩展。这里会涉及到分库分表。          

              

       2.2 、业务层扩展

                一般基于三个方向，业务方向、重要性方向、请求来源方向。

              【业务方向】

                          我们基于业务进行拆分后行成各种业务池（理解为集群），比如，我们上面的酒店预订被拆为用户池、搜索池、酒店详情池、基础数据服务池、运营池、订单池等等。每个池对应着自己的数据库。

         

                  

         针对各个基础业务进行拆分，然后哪个池达到了瓶颈我们就横向扩展哪一个就行了，简单而不粗暴。

           【重要性方向】

             重要性是指将一些重要的服务也就是不能影响我们系统主流程服务放在一起，将一些可以妥协的服务放在一起形成非重要性服务池，为什么要这么设计扩展性呢？是因为，当我们系统面临突然流量激增的时候比如秒杀假期大促等，可以适当的去将非重要性的服务进行降级，从而保重主流程的正常运作。比如我们酒店预订中就可以将运营和相关权益政策服务进行降级，不去请求他们，从而让我们整个系统能保证用户能搜到和订到酒店

                        

           【请求来源方向】

              请求来源是指我们系统被哪些端访问，APP端、网页端、小程序或者公众号等，将这些进行归类进行独立提供服务，还得上面酒店预订系统为例，提供了APP端服务、H5端服务、内部调用服务。