常见的系统架构及演变过程

什么是系统架构：

        系统架构是指系统研发过程中，负责根据需求确定主要的技术选型，主要的开发工具，设计系统的整体框架结构。

        随着互联网的发展，网站应用的规模不断扩大，需求的不断增加，带来的技术上的巨大压力。系统架构也因此不断地更新、升级、迭代。

 单体/集中式架构：

        单体架构应该是我们最先接触到的架构实现了，在单体架构中使用经典的三层模型，即表现层，业务逻辑层和数据访问层。单体架构只适合在应用初期应用功能较少，且访问量不大的情况下使用。

        优点：是性价比很高，开发速度快，成本低

        缺点：代码耦合度高，不易拓展

集群架构：

        集群架构是指将多个服务器组成一个集群，共同分担工作任务，以提高系统的可靠性和性能。这种架构通常用于处理高并发请求、提供高可用服务、实现负载均衡等场景。

        针对单个服务器在访问量越来越大的情况越来越吃力的情况，我们可以考虑服务器的集群话处理。

        集群的部署大大提高了服务的处理能力，同时利用Nginx提供的负载均衡机制，来分发请求，使用户的体验没有改变。

垂直化架构：

        上面的集群部署是可以解决一部分的服务器压力，但是随着用户访问量的增多，集群节点增加到一定阶段的时候，其实作用就已经不是太大了，因为将所有的业务都集中在一起，造成耦合度很高，这时我们可以考虑业务的拆分。来提高系统的性能。比如将原来在一个系统里面的业务拆分为用户系统，订单系统和商品系统。也就是我们讲的垂直化拆分如下：

        服务垂直化拆分后是可以大大的提高整体的服务处理能力，但是也会出现很多的冗余的代码，比如用户系统要操作订单库，要操作商品库，订单系统也有可能要操作用户库和商品库等。

分布式架构：

        分布式架构是将垂直架构中的每一个模块进行核心业务的抽取，抽取之后每个模块成了两部分，一部分是基础服务，一部分是业务功能，通过业务功能取调用基础服务。

        优点：

                解决了垂直式架构各个系统间代码不能相互调用的问题，提高了代码复用和开发效率。

        缺点：

                系统间调用关系错综复杂，难以维护。

       

分布式架构类型：

        面向服务架构(Service Oriented Architecture，SOA)：

        SOA是一种设计方法，其中包括多个服务，而服务之间通过配合最终会提供一系列功能，一个服务通常以独立的形式存在于操作系统进程中，服务之间通过网络调用，而非采用进程内调用的方式进行通信。

        它把业务逻辑抽象成可重复、可组装的服务，通过服务的编排实现业务的快速再生，目的是吧原先固有的业务功能转变成通过的业务服务，实现业务逻辑的快熟复用。

        优点：

                提取公共的功能为服务，提高开发效率，对不同服务进行集群化部署解决系统压力、减少了系统之间的耦合度。

        缺点：

                服务抽取粒度比较大，服务范围划分很难界定。

        

• SOA架构模式实现方案为Web Service或者是ESB企业服务总线。
• 底层通讯协议SOAP协议（Http+XML）实现传输。
• 传统政府、银行项目还是保留地在使用Web Service。

        分布式服务架构（Distributed Service Architecture，DSA)：

         基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理；

         它强调服务的分布式、自治和无中心化，每个服务都可以独立地处理业务请求，并与其他服务进行协作。DSA的目标是打破传统的中心化架构，降低系统的耦合度，提高系统的可扩展性和可靠性。

        微服务架构（MicroServices Architecture，MSA)：

        微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。

         微服务架构强调的一个重点是 "业务需要彻底的组件化和服务化" ,原有的单个业务系统拆分为多个可以独立开发、设计、运行的小应用。

        这些小应用之间通过服务完成交互和集成。每个服务基于单一业务能力构建，运行在自己的进程中，并使用轻量级机制通信，通常是Http API，并能够通过自动化部署机制来独立部署。

        这些服务可以使用不同的编程语言实现，以及不同的数据库存储技术，并保持最低限度的集中式管理。

微服务和SOA的区别及关系：

        微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想      

        通讯协议：

                微服务架构基于SOA架构，继承了SOA架构优点，在微服务架构中去除SOA架构中SOAP协议和ESB企业服务总线，改为http+json形式传输接口。

         服务拆分：

                微服务架构比SOA架构的粒度更加精细，提倡让专业的人去做专业的事。每个服务互不影响。每个服务都是单独独立数据库、redis连接、MQ等。并且都是独立部署，整个服务架构更加轻巧。

        迭代：

                微服务的架构模式比SOA架构模式，更加适合敏捷、高效、快速迭代。

1）SOA 和微服务是一脉相承的，微服务是 SOA 思想的一种提炼，是经过良好架构设计的 SOA，使用一系列微小服务来实现单个应用的方式，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署。

2）微服务与敏捷开发的思想高度结合在一起，微服务框架将能够带来更大的敏捷性，并为构建应用提供更轻量级、更高效率的开发，而 SOA 更适合大型企业中的业务过程编排、应用集成。

3）从服务粒度上，SOA 的服务粒度要粗一些，而微服务倡导服务的细粒度，专注于服务的拆分，重用组合，服务粒度足够小到不能再进行拆分，而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度。微服务是以 SOA 的思想进入到单个业务系统内部实现彻底的组件化和服务化，原有的单个业务系统拆分为多个可以独立开发、设计、运行和运维的小应用，这些小应用可独立地进行开发、管理和加速，应用之间通过服务完成交互和集成，每个小应用除了完成本身的业务功能外，还需要消费外部其它应用暴露的服务，同时也将自身的能力朝外部发布为服务。
4）去中心化：SOA 注重的是系统集成，而微服务关注的完全分离，微服务架构采用去中心化思想，服务之间采用统一的协议和格式，例如 REST、RPC 等轻量协议通信，相比 ESB 更轻量。为了统一管理微服务系统，可以部署一个统一的网关，作为系统的唯一入口。网关封装了系统内部架构，为每个客户端提供一个定制的API。除此之外，网关还可以用于身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。

SOA 更适合需要与许多其他应用程序集成的大型复杂企业的应用程序环境，小型应用程序不适合 SOA 架构，因为它们不需要消息中间件组件。而微服务架构，更适合于较小和良好的分割，基于Web的系统。如果你开发的是互联网应用，并且没有历史遗留问题，请优先考虑采用微服务架构。

分布式服务架构与微服务架构的关系：

        从概念理解：

                分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工。

        从实践的角度来看：

                微服务架构通常是分布式服务架构，反之则未必成立。

• 所以，选择微服务通常意味着需要解决分布式架构的各种难题