大型互联网项目架构的理论知识

Posted 2021-08-08 穷少年

文章目录

• 1.当今大型互联网项目架构目标
• 2. 架构演进
• • 单体架构
  • 垂直架构
  • 分布式架构
  • SOA架构
  • 微服务架构

1.当今大型互联网项目架构目标

• 高性能：访问速度高，用户体验好。
• 高可用：要求服务一直都可以对外使用，一般采用集群方式，即使一个节点宕机了，还有其他节点通过服务。
• 可伸缩：根据具体情况，通过增加/减少硬件，从容提高/降低处理能力。如登录功能模块只使用一台以每秒处理10个请求的服务器，当用户量提升了，现每秒需要处理20个请求，那么可以增加另一台服务器提供登录功能模块的服务。
• 高可扩展：系统间耦合度低，方便通过新增/移除方式，增加/减少新的功能/模块。
• 安全性：保证网站的安全可靠。
• 敏捷性：随需应变，快速响应。

2. 架构演进

随着互联网的发展，网站应用的规模不断扩大，架构也在一步步演变，具体请看下图(从dubbo官网获取)：

单体架构

官网解释：当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

个人理解：业务或功能模块不拆分，放在同一个服务器上运行，**就如我们一开始学习javaweb，写好全部功能，一起打包放入同一个tomcat上运行。

优点：

1. 简单，无论是开发还是部署都很方便，毕竟都是在同一个服务器运行。

缺点：
2. 项目启动慢，因为当你的项目业务需要特别多，功能模块特别多，而又是在同一个服务器上运行，服务器资源毕竟有限，需要全部一口气编译运行才能对外提供服务。
3. 可靠性差，当系统分别有A，B，C功能模块，突然B模块出现bug挂了，而其他模块也无法对外提供服务了。
4. 可伸缩性差，因为全部功能模块都是部署在同一个服务器上，当想要增加某个模块处理能力，也无法为单体功能模块搭建集群，也只能整个服务器增加。
5. 扩展性和可维护性差，因为当系统需要增加一个功能模块E时，需要将原服务器停止，并重新打包部署。
6. 性能低，因为全部压力都在一台服务器上，当用户量很大时，服务器会出现瓶颈。

垂直架构

官网解释：当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

个人理解：将单体架构中的多个模块拆分为互不交互的独立项目，重点是互不交互，如上图，在app1中的A,B都不跟app2中的C、D模块进行交互，他们跟同一个DB交互就有。

优点：

1. 解决了单体架构大部分缺点。项目启动变快，因为功能模块被拆分到两台服务器上运行，不会集中在一台服务器。
2. 可靠性变好，由于AB与CD模块是独立在两台服务器上运行，当B模块bug挂了，并不影响app2的应用。
3. 可伸缩性变好，比如AB功能模块用户访问量大，可以多搭一个app1的应用服务器。
   缺点：
4. 重复功能(重复代码)太多了，冗余很大。
   比如：app1是订单功能项目，aap2 是购物车功能项目，那这两个模块都需要用户信息，而app1，跟app2之间是互不交互的，因此可能会导致，在app1中有用户信息相关代码，而app2中也会有，如下图：
   

分布式架构

官方解释：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

个人解释：将重复的公共业务模块提取出来成分独立的服务，供其他调用者消费，以实现服务的共享和重用。
如上图，模块E是重复公共的，将它提取出来，给app1，app2调用如下图：

垂直架构跟分布式架构的区别：首先他们都是将一个大系统划分成为各个不同功能模块，部署在不同的服务器上，但是垂直架构之间的应用互不交互，而分布式架构之间的应用是可以相互调用访问的。

优点：

1. 解决重复功能(重复代码)太多的问题。

缺点：
根据上图来解释)我们知道三个业务模块运行在3个服务器上，而之间要相互调用，必然是使用网络调用，而网络调用有需要三要素，协议，ip，端口，协议不用说了，关键是ip与端口，若一个规定好E服务的IP端口是 192.168.131.129：8000，而app1，app2在代码中就写好这个地址，这样子就可以正常调用，但是如果E服务的IP端口突然改变为192.168.130.128：7000了，那么就需要修改app1，app2相关信息，实在太麻烦了。
缺点
3. 总结一句话就是：服务提供方一旦发生变更，则所有消费方都需要变更。

SOA架构

为了解决分布式架构的缺点，而产生的SOA架构

ABC是消费方，DEF是服务提供方，而DEF服务将把自己的ip端口信息注册到ESB(服务中介中)，如当A想要调用E的服务的时候，先去ESB中索要E服务的端口ip，当A拿到之后，就去通过网络调用E。而当E服务的ip端口发生改变的时候，E服务会重新将ip端口信息注册到ESB中，并通知A消费方，E服务的ip端口发生改变，请获取最新值，之后当A消费方又要调用E服务的时候，则重新去获取最新IP端口，完全不用想当初一样，修改ip端口什么乱七八糟操作。

ESB服务总线，主要是提供了一个服务于服务之间的交互，包含的功能如：负载均衡，流量控制，加密处理，服务监控，异常处理，监控告急等等，dubbo就是做这个任务的。

ESB又叫服务中介，中介嘛，大家都知道很多东西都交给他，他负责搞定大部分事情。

微服务架构

微服务架构是在SOA上做的升华，微服务架构强调的一个重点是 “业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发，设计，运行的小应用，这些小应用之间通过服务完成交互和集成。

业务需要彻底的组件化和服务化，组件化是重点理解，组件故名就是可以重复应用的。其次，单个业务系统会拆分为多个可以独立开发，设计，运行的小应用，独立开发、设计、运行 是重点理解，则说明一个功能模块可以直接在服务器上运行，拥有自己的数据库。

优点：

1. 服务实现组件化：开发者可以自由选择开发技术，也不需要协调其他团队，只需要把自己那个服务彻底实现，并对外提供接口即可。
   服务之间交互一般使用REST API
2. 去中心化，每个微服务有自己私有的数据库持久化业务数据。
3. 自动化部署：把应用拆分成为一个一个独立的单个服务，方便自动化部署、测试、运维。