• 网站的架构模式演变过程


    传统架构(单点应用)-->分布式架构(以项目进行拆分)-->SOA架构(面向服务架构)

    项目表达的意思:包含业务逻辑层和视图层,项目包含:前台项目(提供给用户)和后台项目(维护管理)

    服务表达的意思:只包含业务逻辑层,没有视图层。

    传统架构

      1.单体应用架构

        

         

          

         

               

            

      2.集群应用架构

        把同一个业务部署在不同的服务器上

                     

         特点:项目采用多台服务器(集群)部署

        优点:

          支持高可用

          支持高并发

        问题1:session如何共享?

            使用Redis Cluster集群方案

        问题2:这些集群的服务器,用户的请求该怎么转发?

            使用nginx服务器来完成分发请求,实现负载均衡策略。

      

      3.高并发架构

    数据库压力变大:集群方案nginx+tomcat将应用层的性能进行有效的提升,但是数据库负载压力慢慢增加,如何来减轻数据库访问压力?

    解决方案:

      1.读写分离

        主从数据库之间进行数据同步。master负载增删改操作,slave负载读操作。mysql本身就提供了master-salve的方式完成主从复制功能。

      2.使用搜索引擎缓解数据库的访问压力和提高能力

        数据库做读库的情况下,数据库本身对模糊查询的功能支持不是特别优秀,像电商类的网站,搜索是非常核心的功能模块。即使做了读写分离。这个问题也不能有效解决电商网站查询(分词技术)等。针对该问题,有必要引入搜索引擎技术。

       

      3.使用缓存技术
        随着访问量的持续增加,数据库的访问压力变得越来越大(虽然做了主从复制)。对于这些热点数据(用户访问频繁的信息),如果每次都到数据库中进行查询。(很多通用查询的功能)。放在内存中又特别不合适。(手机登录验证码操作,为了IP限制频繁访问服务器。。。)尝试使用Redis

       4.数据库的水平/垂直拆分

         垂直扩展能力终归还是有限的。

           单个表:1000万->1个亿数据(单个表的数据能力终归还是有限的)

        表:垂直拆分

          id,name,age,bire....表中的字段(按字段拆分)

        热数据/冷数据-->垂直拆分方案。

        表:水平拆分

          按照:时间、地区、(业务逻辑进行拆分)

        分库分表:

          采用第三方中间件:mycat/sharding-jdbc/drds

                  

          当前状态的特点:

          通过设计保证高可用、高并发(不断对服务器进行扩容。。。)

       问题1:各方面的成本不断增加

       问题2:可维护性差

       问题3:可扩展性差

         问题4:协同开发不方便。(大家都去改相同的业务代码,容易发生代码冲突)

         问题5:单体架构(随着业务的不断增加,代码会变得越来越多)。导致服务部署时,文件变得越来越大。

       

          4.垂直应用架构   

        当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的web框架(mvc)是关键。

                   

                     水平拆分:   

           把一个大的单体应用,拆分成多个小应用。

           横着拆:

              exam:   exam-pojo、exam-mapper、exam-service、exam-web

               

           解决的问题:

            1.模块复用

            2.解决服务器部署的内容变小

            闲置了大量服务器(如果用户对某个层访问量过大,只需要把该层业务多部署下服务即可)

         垂直拆分:

          将一个大的应用拆成互不相关的几个小应用,每个应用是独立部署的。

          

           解决问题:

                问题2:可维护性(如果想做需求变更,只需要调整某个应用模块即可)

                             问题3:可扩展性(随着业务的不断增加,只需要创建新的应用即可)

                问题4:协同开发方便(不同团队修改不同的业务)

                   问题5:性能扩展/部署内容大小(只需要对访问量大的服务器多部署几台)

           问题1:

            (客户对页面的要求变得越来越高,修改会越来越频繁)页面变化大,每一个应用从头到尾都是完整的,如果客户要对页面进行修改,这个应用就要重新部署。

          问题2:

            随着业务的不断增加,应用模块越来越多,每个模块之间一定需要业务进行交互

       

    =========================================================================================================================================                                                       

    分布式架构

      

      分布式:每一个业务拆分成多个子业务,部署在不同的服务器上。

      针对如上情况:  

         问题1:客户对页面的要求变得越来越高,修改会越来越频繁)页面变化大,每一个应用从头到尾都是完整的,如果客户要对页面进行修改,这个应用就要重新部署。

            答:界面+业务逻辑实现分离(前后端分离开发)【横着拆,水平拆分】

                  

         问题2:随着业务的不断增加,应用模块越来越多,每个模块之间一定需要业务进行交互

            

             分析:

              以前如果在同一台服务器上,(模块的依赖进程来完成调用)

              通过上图发现,不同的应用部署在不同的服务器上,服务和服务之间调用【进程间调用】

             答:

               

           架构的改变一定会带来一些新的技术和新的问题

             分布式事务、分布式锁、分布session问题、分布式日志管理。

            问题1:服务越多服务和服务之间的调用会变得非常混乱。

            问题2:服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现(因为无法确定访问量对应的服务的情况)

                加入会议管理功能访问量小,但部署了100台服务器。支付管理功能访问量大,但只部署了20台服务器。

             

    总结:分布式架构和传统架构的区别

      分布式的项目粒度分的更加细、逐步适合于互联网公司规模人数开发,耦合度降低。

      问题:Maven聚合项目是不是分布式项目?答案:不一定。

      解释:将传统的项目以maven聚合方式分为3个项目:itmayiedu_web、itmayiedu_service、itmayiedu_dao。最终打成一个war包,区别在于打成的是jar包还是war包,如果打成单个则非分布式。否则打成多个,多个jvm相互通讯,因此就是分布式。

    =========================================================================================================================================

    SOA架构

      SOA架构代表面向服务架构,它也是基于分布式架构演变来的,俗称服务化,可以理解为面向于业务逻辑开发层。把共同的业务代码进行抽取出来的,然后提供给其他接口进行调用。服务于服务之间采用RPC远程调用技术。它可以解决分布式之出现的混乱调用问题

      服务概念:将共同的业务逻辑进行拆分、拆分成独立一个项目进行部署,没有视图层。服务概念可以理解为接口。

      服务治理中间件:基于访问压力实时管理集群容量,提高集群利用率,提高机器利用率的资源调度和治理中心。

      SOA的通俗理解:

      

      

    =========================================================================================================================================

    微服务架构

    微服务:单体应用拆分成多个互不相干的小应用,每个小应用称为微服务。

    微服务架构产生的原因

      首先微服务架构基于SOA架构演变来的。

      SOA架构缺点:

        1.依赖于中心化服务发现机制

        2.因为SOA架构采用SOAP协议(Http+XML),因为XML传输协议比较占用宽带,整个XML报文中有非常大冗余数据,所以在微服务架构中以json轻量级方式代替xml报文传输。

        3.服务管理非常混乱、缺少服务管理和治理设施不完善。

    微服务架构模式

      微服务架构基于SOA架构演变来的,比SOA架构上粒度上更精细。让更专业的人做更专业的事情,目的是为了提高效率。每个服务与服务之间互不影响,每个服务必须独立部署(独立数据库、独立redis等),微服务架构更加体现轻量级,采用restful风格提供API,也就是Http协议+JSON格式,更加轻巧,更加适合于互联网公司敏捷开发、快速迭代产品。

                                                             

                

                                                                   

    微服务架构和SOA架构的区别

      1.微服务架构基于SOA架构演变来的,继承SOA架构的优点,在微服务架构中去除SOA架构中的ESB消息总线,采用http+json(restful)进行传输。

      2.微服务架构比SOA架构粒度会更加精细,让更专业的人做更专业的事情,目的是为了提高效率。每个服务与服务间互不影响,在微服务架构中,每个服务必须独立部署,微服务架构更加轻巧、轻量级。

      3.SOA架构中可能数据库存储会发生共享,微服务强调每个服务都是单独数据库,保证每个服务间不相互影响。

      4.项目体现特征:微服务架构比SOA架构更加适合于互联网公司敏捷开发、快速迭代版本,因为粒度非常精细。

    你还有很多未完成的梦,你有什么理由停下脚步
  • 相关阅读:
    9月9日刷题
    7-4日刷题
    7-3日刷题
    7-2日刷题
    The Key To Accelerating Your Coding Skills
    初识机器学习
    python数据分析与量化交易
    部署远程jupyter
    SQLserver2008一对多,多行数据显示在一行
    kvm虚拟化
  • 原文地址:https://www.cnblogs.com/quanziheng/p/13304119.html
Copyright © 2020-2023  润新知