单体架构（all in one）

• 所有模块都在一起，技术也不分层。

• 在单机上部署所有的应用程序和软件。

• 所有的代码都写在JSP里面，所有代码都写在一起，这种方式称为all in one。 特点： 1.不具备代码的可维护性。 2.容错性差。（容错性是指软件检测应用程序所运行的软件和硬件中发生的错误并从错误中恢复的能力，可以从系统的可靠性，可用性，可测性等几个方面衡量） 因为所有代码都写在JSP页面里，当因为用户或某些原因发生异常时：用户可以直接看到异常错误信息；异常会导致服务器宕机。

• 单体地狱： 只需一个应用，将所有功能部署在一起，以减少部署节点和成本。

1.分层开发：解决单体架构容错性差的问题，同时提高了代码的维护性。 2.MVC架构（Web应用程序的设计模式） 3.服务器的部署分离。 特点： 1.MVC分层开发：解决容错性问题。 2.数据库和项目部署分离。 问题： 1.高并发：随着用户访问量的持续增加，单台服务器无法满足用户访问需求。 解决方案： 1.集群

集群操作可能遇到的问题

• 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。
• 如何保证高可用：避免单点。

• 高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
• 高并发相关常用的一些指标
• 响应时间（Response Time）：系统对请求做出响应的时间。
• 吞吐量（Throughput）：单位时间内处理的请求数量。
• QPS（Query Per Second）：每秒响应请求数。
• 并发用户数：同时承载正常使用系统功能的用户数量。 提高系统的并发能力 1.垂直扩展：提升单机处理能力。
• 增强单机硬件性能
• 提升单机架构性能 2.水平扩展
• 只要增加服务器数量，就能线性扩充系统性能。

• 集群：同一个业务，部署在多个服务器上。

特点：

• 项目采用多台服务器（集群）部署。 优点： 1.支持高并发 2.支持高可用

问题1： session数据如何共享？

• RedisCluster集群方案-读取session，获取session

问题2： 这些集群的服务器，用户的请求怎么转发？

• 用nginx服务器来完成分发请求，实现负载均衡策略机制。

集群操作中的高并发导致数据库压力增加

• 集群方案nginx+tomcat将应用层的性能进行有效的提升，但是数据库的负载压力慢慢增加，如何提高数据库的负载的解决方案：

• 读写分离：主从数据库之间进行数据同步。master（写）负责数据库的增删改操作，slave（读）负责数据库的查询操作。
• MySQL提供了master-slave的方式完成主从复制功能。

使用搜索引擎缓解数据库访问压力，提高数据库能力

• 数据库在进行读取数据库的查询操作时，数据库本身对模糊查询的功能支持不是特别好。例如电商类网站，搜索功能是非常核心的功能模块，即使做了读写分离，也不能解决电商网站查询（分词技术）等，针对这样的问题，引入搜索引擎技术作为解决方案。
• 目前主流的搜索引擎技术： 1.solr 2.elasticsearch 3.whoosh（阿里）

引入缓存机制减轻数据库的访问压力

• 随着访问量的持续增加，即便做了主从复制，数据库的访问压力还是越来越大。对于热点数据的查询，用户需要频繁地访问，如果每次都要到数据库中查询，包括很多的通用查询功能，数据库中的数据不宜都放在内存中。例如手机登录的验证码操作，为了IP限制频繁访问服务器等。
• 使用Redis实现缓存机制。

数据库的水平/垂直拆分

• 服务器的垂直扩展能力有限。
• 表：垂直拆分 1.数据库表字段的分离成新表。 2.热数据/冷数据的分离成新表。
• 表：水平拆分 1.数据库表数据的分离成新表。 2.按照时间，地区，业务逻辑进行水平数据拆分成新表。
• 分库分表 1.采用第三方数据库中间件
• mycat
• sharding-jdbc
• drds（阿里）

集群状态特点

• 通过集群设计，不断对服务器扩容可以保证高可用、高并发。
• 问题： 1.服务器成本高，包括服务器维护成本，人工维护成本。 2.应用可维护性差。 3.应用可扩展性差，组件重用性低。 4.协同开发困难，会修改相同的业务代码，容易造成代码冲突错误。 5.单体架构，随着业务的不断增加，代码变得越来越多，导致服务部署时，文件变得越来越大。

水平分层架构

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

• 水平拆分：

  • 按照业务对系统进行划分: 比如原来的系统中包括了交易,运营两大类,按照水平拆分的原则进行拆分.系统可以拆分成:交易系统,运营系统
  • 优点: 不同业务,往往性能要求,以及请求量是不一样的.拆分后保证业务之间的可用性影响最小化
  • 缺点: 拆分过程中,多个系统中可能存在重复的轮子,难于维护

• 拆分完成后对拆分的项目进行聚合，提出概念父工程。 IDEA示例

• 在pom.xml中：dependencies-直接使用，dependencyManagement-声明作用（子类不需要再依赖版本号，统一管理开发版本）

• 利用maven做模块的拆分和聚合

• 解决问题：

1.模块复用 2.解决服务器部署的内容变少 3.闲置出大量的服务器，可以用于当用户对某个层访问量过大时，只需要将该层业务部署在较多的服务器上即可；利用闲置服务器作为其他服务，例如云服务器，阿里云，百度云等等；

• 垂直拆分： 拆分的各个小应用之间相互独立,互不影响

  • 将同样的系统按照应用场景(调用方)进行拆分: 比如一个交易系统的支付模块,上游有用户支付和商家支付两个调用流程.按照垂直拆分的规则就可以将支付模块拆分为用户支付和商家支付
  • 优点: 按需配给(预估调用方的流量,配置对应的机器数),各个垂直调用之间相互不影响,通过配置可以进行上游调用降级
  • 缺点: 几乎完全重复的轮子

• 特点：

1.维护性强：如果想要做需求变更，只需要调整某个应用某块即可。 2.功能扩展性好：随着业务的不断增加，只需要创建新的应用模块即可。 3.协同开发方便：不同的团队修改不同的业务。 4.部署内容灵活，性能扩展好：只需要对访问量大的模块多部署服务器。 问题： 1.前端页面变化变大：当用户对页面的要求变高时，需要频繁修改页面，由于每个应用的各个层次都是完整的，如果要对页面进行修改，应用服务需要重新部署。 2.各个模块间的业务交互困难：随着业务的不断增加，应用模块越来越多，各个模块间的业务交互变得困难。

分布式服务架构

• 分布式：将一个业务拆分成多个子业务，部署在不同的服务器上。
• 分布式服务架构：当分层应用越来越多，应用之间的交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能够更快速的响应多变的市场需求。此时用于提高业务复用以及整合的分布式服务框架RPC是关键。
• 解决方案： 1.前端页面变化变大：当用户对页面的要求变高时，需要频繁修改页面，由于每个应用的各个层次都是完整的，如果要对页面进行修改，应用服务需要重新部署。

分布式解决方案：界面和业务逻辑实现分离，也就是前后端分离开发，水平拆分。

2.各个模块间的业务交互困难：随着业务的不断增加，应用模块越来越多，各个模块间的业务交互变得困难。

问题分析：在一台服务器上时，各个模块之间可以通过依赖完成调用（进程）；不同的应用部署在不同的服务器上时，要通过服务与服务之间完成调用。

分布式解决方案：

• RPC：Remote Procedure Call-远程过程调用，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

• 分布式带来的技术问题： 1.分布式事务问题 2.分布式锁问题 3.分布式session问题 4.分布式日志管理问题

• 问题：

1.当服务越来越多，服务和服务之间的调用会变得异常混乱 2.当服务越来越多，容量的评估，小服务资源浪费等问题逐渐显现

面向服务架构（SOA）

• 当服务越来越多，容量的评估，小服务资源浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群的利用率。此时，用于提高机器利用率的资源调度和治理中心SOA是关键。
• 服务管理中间件：
  • Dubbo
  • SpringCloud
• 基于访问压力实时管理集群容量，提高集群的利用率。
• SOA架构特点:
  • 底层基于SOAP或者ESB消息总线实现
  • 底层使用http协议+重量级数据交换格式进行通信

微服务架构

• 微服务：单体应用拆分成互不相干的小应用，每个小应用称为微服务
• 微服务体现更加轻量级的架构
  • RESTful API:Http协议+json格式
  • 更适合敏捷开发,快速迭代产品
  • 通过RPC远程调用,服务与服务之间都是可以相互实现通信
• 微服务架构从SOA架构演变而来
  • 服务化功能在SOA层已经实现
  • 微服务在单独服务层进行细分服务
• 问题：

1.微服务架构与SOA架构的区别?

- 微服务架构基于SOA架构演变而来,继承SOA架构的优点.微服务去除了SOA架构中的ESB消息总线,
  采用http+json(RESTful)轻量级数据通信
- 微服务架构比SOA架构的粒度更加精细,目的是为了提高效率.每个服务与服务之间互不影响,
  在微服务架构中,每个服务必须独立部署,微服务架构更加轻巧,轻量级
- SOA架构中可能会共享数据库.微服务架构强调单独每个服务都是单独数据库,保证每个服务与服务之间互不影响
- 微服务项目粒度更加精细,比SOA架构更适合公司敏捷开发,快速迭代版本

2.构建单体应用时，需要进行相关配置，例如SSM项目：web.xml,相应的所有jar包，相应的配置文件。因而在拆分构建微服务时，需要进行大量的服务项目的创建。 解决方案: SpringBoot。

SpringBoot

• SpringBoot：一个简化Spring开发的框架。用来监护Spring应用开发，约定大于配置，去繁就简，快速应用开发。
• 目的：为了简化代码的初始化和开发配置。

微服务优点

• 服务化的拆分粒度变得更细，服务的复用性强。提高开发效率。
• 可根据需求自定义优化方案，选择最新技术进行微服务模块的开发修改。
• 适合互联网项目，开发效率高，迭代周期短。

微服务缺点

• 微服务过多，服务的管理成本高。
• 不利于服务的部署。部署不方便，部署成本高。Docker（镜像/容器），k8s
• 技术难点增加，例如分布式事务，分布式锁，分布式Session，分布式日志管理
• 对团队技术能力要求高，Dubbo，SpringCloud

• IaaS： Infrastructure as a Service，即基础设施即服务。消费者通过Internet 可以从完善的计算机基础设施获得服务。这类服务称为基础设施即服务。基于 Internet 的服务（如存储和数据库）是 IaaS的一部分。
• PaaS： Platform as a Service，即平台即服务。云计算时代相应的服务器平台或者开发环境作为服务进行提供。
• SaaS：Software-as-a-Service，即软件即服务，通过网络提供软件服务。

服务网格架构（Service Mesh）

• 服务网格作为服务间通信的基础设施层，可以比作是应用程序或者说微服务间的 TCP/IP，负责服务间的网络调用、熔断、限流和监控。
• 使用服务网格我们也就不需要关心服务间的那些原来是由应用程序或者其他框架实现的事情

特点:

• 应用程序间通讯的中间层。
• 轻量级网络代理。
• 应用程序无感知。
• 解耦应用程序的重试/超时、监控、追踪和服务发现。