1.1、衡量网站的性能指标

• 响应时间：指执行一个请求从开始到最后收到响应数据所花费的总体时间。
• 并发数：指系统同时能处理的请求数量。
  • 并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
  • 请求数：也称为QPS(Query Per Second) 指每秒多少请求
  • 并发用户数：单位时间内有多少用户
• 吞吐量：指单位时间内系统能处理的请求数量。
  • QPS：Query Per Second 每秒查询数。
  • TPS：Transactions Per Second 每秒事务数。
  • 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
  • 一个页面的一次访问，只会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS

1.2、集群和分布式

• 集群：很多“人”一起 ，干一样的事。（一个业务系统，部署在多台服务器上）
• 分布式：很多“人”一起，干不一样的事。这些不一样的事，合起来是一件大事。（一个大的业务系统，拆分为小的业务模块，分别部署在不同的机器上）

2、架构演进

随着互联网的发展，互联网企业的业务也在不断的飞速发展，进而导致系统的架构也在不断的发生着变化。总体来说，系统的架构大致经历了：单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构的演变。

2.1、单体应用架构（单机单体架构、集群单体架构）

在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。比如，大家都很熟悉的电商系统，里面涉及的业务主要有：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等等模块，初期我们会将所有模块写到一个Web项目中，然后统一部署到一个Web服务器中。

优点： 简单：开发部署都很方便，小型项目首选

缺点： 项目启动慢 可靠性差 可伸缩性差 扩展性和可维护性差 性能低

2.2、垂直架构（拆分成多个单体架构）

垂直架构是指将单体架构中的多个模块拆分为多个独立的项目，形成多个独立的单体架构。

垂直架构根据业务属性将一个大的单体应用拆分成多个模块或子系统，子系统之间没有直接关联。 垂直架构相较于单体架构而言，进行了部分解耦，但是不够彻底，在各个子系统相互依赖的代码和模块中，存在模块功能重复开发和重复代码拷贝的情况。

垂直架构存在的问题： 重复功能太多。

2.3、分布式架构（重复模块抽取为公共服务）

将系统演变为垂直应用架构之后，当垂直应用越来越多时，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务，供其他系统或者业务模块调用，这就是分布式架构。

分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务，供其他调用者消费，以实现服务的共享和重用。

这种架构的优点如下：

1. 将重复的业务代码抽象出来，形成公共的访问服务，提高了代码的复用性。
2. 可以有针对性地对系统和服务进行性能优化，以提升整体的访问性能。

这种架构的缺点如下：

1. 服务之间直接调用，服务提供方地址等信息一旦产生变更，所有消费方都需要变更。
2. 系统之间的调用关系变得复杂，系统之间的依赖关系变得复杂，系统维护成本高。

在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。分布式系统架构如下图示例：

RPC：Remote Procedure Call 远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如：HTTP REST风格，Java RMI规范、WebService SOAP协议、Hession等等。

2.4、SOA架构（调度中心）

在分布式架构下，当部署的服务越来越多时，重复的代码就会变得越来越多，不利于代码的复用和系统维护。为此，我们需要增加一个统一的调度中心对集群进行实时管理，这就是SOA（Service-Oriented Architecture，面向服务的架构）架构。

这种架构的优点是通过注册中心解决了各个服务之间服务依赖和调用关系的自动注册与发现。

这种架构的缺点：服务之间的依赖与调用关系复杂，增加了测试和运维的成本。

2.5、微服务架构

微服务架构是在SOA架构的基础上进行进一步的扩展和拆分。在微服务架构下，一个大的项目拆分为一个个小的可独立部署的微服务，每个微服务都有自己的数据库。微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成。

微服务架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
• 面向服务：微服务对外暴露业务接口
• 自治：团队独立、技术独立、数据独立、部署独立
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

优点：服务彻底拆分，各服务独立打包、独立部署和独立升级。每个微服务负责的业务比较清晰，利于后期扩展和维护。微服务之间可以采用REST和RPC协议进行通信。

缺点：架构非常复杂，运维、监控、部署难度提高。开发的成本比较高。涉及到各服务的容错性问题。涉及到数据的一致性问题。涉及到分布式事务问题

3、分布式和微服务架构的区别

总的来说，分布式主要是有多个服务器，而微服务主要注重服务的拆分，微服务并不一定是部署在多个服务器上，也可能只是在一个服务器上（基本很少见）。

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。

微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上也可以是同一个服务器。

分布式服务架构强调的是服务化以及服务的分散化，而微服务则更强调服务拆分的专业化和精细分工。分布式也可以理解为属于微服务，但可能服务拆分没那么细致，而微服务架构通常也是分布式的架构。

4、框架

Dubbo 是 SOA 时代的产物，SpringCloud 是微服务时代的产物。

4.1、Dubbo

Dubbo框架是由阿里巴巴开发的开源式的分布式服务化治理框架，它会通过RPC请求方式访问。Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战。

4.2、Spring Cloud

Spring Cloud不是一个单独框架，它是一整个系列的框架合计，它是基于HTTP（s）的RETS服务构建服务体系的。Spring Cloud能够帮助架构师构建一整套完整的微服务架构技术生态链。

SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。 SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验：

springcloud 与 springboot的版本兼容关系：

4.3、微服务框架对比