1. 微服务架构介绍

1.1 什么是微服务架构？

形像一点来说，微服务架构就像搭积木，每个微服务都是一个零件，并使用这些零件组装出不同的形状。通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。

如果学科派一点，微服务架构就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为HTTP RESTful API）实现通信。

追本溯源，Martin Folwer对微服务架构的定义是：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

对于我个人，我更喜欢一种延续性的解释，微服务架构≈ 模块化开发+分布式计算。不管微服务架构的定义怎么样，都是在描述一个核心思想：把大系统拆分成小型系统，把大事化小，以降低系统的复杂性，从而大幅降低系统建设、升级、运维的风险和成本。

顺带提一下，亚马逊创始人Jeff Bezos在2002年就说过：所有团队的模块都要以Service Interface的方式将数据和功能开放出来。不这样做的人会被炒鱿鱼。这才是思路超前的大牛。

需要注意的是“微服务”与“微服务架构”是有本质区别的。“微服务”强调的是服务的大小，它关注的是某一个点。而“微服务架构”则是一种架构思想，需要从整体上对软件系统进行通盘的考虑。

Chris Richardson说：“微服务”是一个很糟糕的名字，它导致开发人员创建了许多粒度很小的服务，每个服务拥有一个单独的REST端点。不仅如此，这个名字还暗示了微服务在开发者心目中的重要位置。例如，人们会说“我们可以用微服务来解决这个问题”；我也看到了越来越多的“某某微服务框架”，而实际上，这些框架跟微服务架构不一定有太多联系，它们只是简单的Web框架（如：spring-boot）。使用“微服务架构”这个名字会更恰当些。它是一种架构风格，它把一系列协作的服务组织成一个系统来支撑业务。

1.2常见的微服务组件

1.服务注册:服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。

2.服务发现:服务调用方从服务注册中心找到自己需要调用的服务的地址。

3.负载均衡:服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。

4.服务网关:服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。

5.配置中心:将本地化的配置信息（properties,

xml, yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。

6.API管理:以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。

7.集成框架:微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。

8.分布式事务:对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。具有代表性的有spring transaction

9.调用链:记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。具有代表性的有pinpoint.

10.支撑平台:系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过Docker等工具来中和这些微服务架构带来的弊端。 例如:持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

一般情况下，如果希望快速地体会微服务架构带来的好处，使用Spring Cloud提供的服务注册（Eureka）、服务发现（Ribbon）、服务网关（Zuul） 三个组件即可以快速入门。其它组件则需要根据自身的业务选择性使用。

1.3微服务架构有哪些优势劣势？

要谈优势，就一定要有对比，我们可以尝试着从两个维度来对比:

1.3.1单体架构和微服务架构的对比

【结论】:

n对于简单项目来说，单体架构5胜8败。

（优势项：开发效率、上手难度、运维效率、硬件需求、项目成本；劣势项：系统设计（高内聚低耦合）、系统设计（扩展性）、需求变更响应速度、系统升级效率、知识积累、非功能需求、职责、成就感、风险）

n对于复杂项目来说，单体架构2胜11败。

（优势项：上手难度、运维效率；劣势项：硬件需求、项目成本、开发效率、系统设计（高内聚低耦合）、系统设计（扩展性）、需求变更响应速度、系统升级效率、知识积累、非功能需求、职责、成就感、风险；）

1.3.2微服务与共享库的对比.,

1.3.3什么场景需要用微服务架构？

看了上面的比较，微服务架构可以说是以压倒性的优势胜过单体架构和共享库，会让人产生一种错觉，微服务架构就是软件开发中的银弹。

但是，正如大家所了解的，软件研发是一个系统工程，它没有银弹，不能够一招鲜吃遍天。正如当年的CMMI和敏捷方法一样，敏捷虽好，但它不一定能适用于所有的场景，它对组织环境、团队氛围、沟通方式、技术能力这些都是有一些要求的，如果用不好，反而会带来一些负面影响。

那么，我们什么时候需要采用微服务呢？从我个人的经验来看，我认为有三种场景可以考虑使用微服务。

1.规模大（团队超过10人）

2.业务复杂度高（系统超过5个子模块）

3.需要长期演进（项目开发和维护周期超过半年）

2.微服务架构身份认证

2

2.1背景介绍

从单体应用架构到分布式应用架构再到微服务架构，应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化，身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用，如何保证高效安全的身份认证？面对外部的服务访问，该如何提供细粒度的鉴权方案？本文将会为大家阐述微服务架构下的安全认证与鉴权方案。

【单体应用VS微服务】

随着微服务架构的兴起，传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大。单体应用体系下，应用是一个整体，一般针对所有的请求都会进行权限校验。请求一般会通过一个权限的拦截器进行权限的校验，在登录时将用户信息缓存到session中，后续访问则从缓存中获取用户信息。

而微服务架构下，一个应用会被拆分成若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问用户以及其权限。尤其当访问来源不只是浏览器，还包括其他服务的调用时，单体应用架构下的鉴权方式就不是特别合适了。在为服务架构下，要考虑外部应用接入的场景、用户-服务的鉴权、服务-服务的鉴权等多种鉴权场景。

David

Borsos在伦敦的微服务大会上提出了四种方案：

2.2常见的四种解决方案

2.2.1单点登录（SSO）

这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显。

2.2.2分布式Session

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为key来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。

2.2.3客户端Token

令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos更喜欢使用JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。

2.2.4客户端Token与API网关结合

这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。在请求时，网关将原始用户令牌转换为内部会话ID令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。

2.3微服务常见安全认证方案HTTP基本认证

HTTP Basic Authentication（HTTP基本认证）是HTTP 1.0提出的一种认证机制，HTTP基本认证的过程如下：

1.客户端发送HTTP Request给服务器。

2.因为Request中没有包含Authorization header，服务器会返回一个401 Unauthozied给客户端，并且在Response的Header "WWW-Authenticate"中添加信息。

3.客户端把用户名和密码用BASE64加密后，放在Authorization Header中发送给服务器，认证成功。

4.服务器将Authorization Header中的用户名密码取出，进行验证， 如果验证通过，将根据请求，发送资源给客户端。

2.3.1Session的认证

基于Session的认证应该是最常用的一种认证机制了。用户登录认证成功后，将用户相关数据存储到Session中，单体应用架构中，默认Session会存储在应用服务器中，并且将Session ID返回到客户端，存储在浏览器的Cookie中。

但是在分布式架构下，Session存放于某个具体的应用服务器中自然就无法满足使用了，简单的可以通过Session复制或者Session粘制的方案来解决。

Session复制依赖于应用服务器，需要应用服务器有Session复制能力，不过现在大部分应用服务器如Tomcat、JBoss、WebSphere等都已经提供了这个能力。

除此之外，Session复制的一大缺陷在于当节点数比较多时，大量的Session数据复制会占用较多网络资源。Session粘滞是通过负载均衡器，将统一用户的请求都分发到固定的服务器节点上，这样就保证了对某一用户而言，Session数据始终是正确的。不过这种方案依赖于负载均衡器，并且只能满足水平扩展的集群场景，无法满足应用分割后的分布式场景。

在微服务架构下，每个微服务拆分的粒度会很细，并且不只有用户和微服务打交道，更多还有微服务间的调用。这个时候上述两个方案都无法满足，就要求必须要将Session从应用服务器中剥离出来，存放在外部进行集中管理。可以是数据库，也可以是分布式缓存，如Memchached、Redis等。这正是David Borsos建议的第二种方案，分布式Session方案。

2.3.2基于Token的认证

随着Restful API、微服务的兴起，基于Token的认证现在已经越来越普遍。Token和Session ID不同，并非只是一个key。Token一般会包含用户的相关信息，通过验证Token就可以完成身份校验。像Twitter、微信、QQ、GitHub等公有服务的API都是基于这种方式进行认证的，一些开发框架如OpenStack、Kubernetes内部API调用也是基于Token的认证。基于Token认证的一个典型流程如下：

1.用户输入登录信息（或者调用Token接口，传入用户信息），发送到身份认证服务进行认证（身份认证服务可以和服务端在一起，也可以分离，看微服务拆分情况了）。

2.身份验证服务验证登录信息是否正确，返回接口（一般接口中会包含用户基础信息、权限范围、有效时间等信息），客户端存储接口，可以存储在Session或者数据库中。

3.用户将Token放在HTTP请求头中，发起相关API调用。

4.被调用的微服务，验证Token权限。

5.服务端返回相关资源和数据。

基于Token认证的好处如下：

1.服务端无状态：Token机制在服务端不需要存储session信息，因为Token自身包含了所有用户的相关信息。

2.性能较好，因为在验证Token时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。

3.支持移动设备。

4.支持跨程序调用，Cookie是不允许垮域访问的，而Token则不存在这个问题。

5.下面会重点介绍两种基于Token的认证方案JWT/Oauth2.0。

2.3.2.1JWT介绍

JSON Web Token（JWT）是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（RFC 7519）。来自JWT RFC 7519标准化的摘要说明：JSON Web Token是一种紧凑的，URL安全的方式，表示要在双方之间传输的声明。JWT一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该Token也可直接被用于认证，也可被加密。

2.3.2.2JWT认证流程

1.客户端调用登录接口（或者获取token接口），传入用户名密码。

2.服务端请求身份认证中心，确认用户名密码正确。

3.服务端创建JWT，返回给客户端。

4.客户端拿到JWT，进行存储（可以存储在缓存中，也可以存储在数据库中，如果是浏览器，可以存储在Cookie中）在后续请求中，在HTTP请求头中加上JWT。

5.服务端校验JWT，校验通过后，返回相关资源和数据。

2.3.2.3JWT结构

JWT是由三段信息构成的，第一段为头部（Header），第二段为载荷（Payload)，第三段为签名（Signature）。每一段内容都是一个JSON对象，将每一段JSON对象采用BASE64编码，将编码后的内容用.链接一起就构成了JWT字符串。如下：

header.payload.signature

1.头部（Header）

头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。

{

"typ":"JWT",

"alg":"HS256"

}

在头部指明了签名算法是HS256算法。

2.载荷（payload）

载荷就是存放有效信息的地方。有效信息包含三个部分：

l标准中注册的声明

l公共的声明

l私有的声明

标准中注册的声明（建议但不强制使用）：

liss：JWT签发者

lsub：JWT所面向的用户

laud：接收JWT的一方

lexp：JWT的过期时间，这个过期时间必须要大于签发时间

lnbf：定义在什么时间之前，该JWT都是不可用的

liat：JWT的签发时间

ljti：JWT的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

公共的声明 ：

公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密。

私有的声明 ：

私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

示例如下：

{"iss": "Online JWT Builder",

"iat": 1416797419,

"exp": 1448333419,

"aud": "www.primeton.com",

"sub":"devops@primeton.com",

"GivenName": "dragon",

"Surname": "wang",

"admin": true

}

3.签名（signature)

创建签名需要使用Base64编码后的header和payload以及一个秘钥。将base64加密后的header和base64加密后的payload使用.连接组成的字符串，通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

比如：HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload), secret)

2.3.2.4JWT的优点

1.跨语言，JSON的格式保证了跨语言的支撑

2.基于Token，无状态

3.占用字节小，便于传输

2.3.2.5Token注销

Token的注销，由于Token不存储在服务端，由客户端存储，当用户注销时，Token的有效时间还没有到，还是有效的。所以如何在用户注销登录时让Token注销是一个要关注的点。一般有如下几种方式：

1.Token存储在Cookie中，这样客户端注销时，自然可以清空掉

2.注销时，将Token存放到分布式缓存中，每次校验Token时区检查下该Token是否已注销。不过这样也就失去了快速校验Token的优点。

3.多采用短期令牌，比如令牌有效期是20分钟，这样可以一定程度上降低注销后Token可用性的风险。

2.3.3OAuth 2.0介绍

OAuth的官网介绍：An open protocol to allow secure

API authorization in a simple and standard method from desktop and web

applications。OAuth是一种开放的协议，为桌面程序或者基于BS的web应用提供了一种简单的，标准的方式去访问需要用户授权的API服务。OAUTH认证授权具有以下特点：

1.简单：不管是OAuth服务提供者还是应用开发者，都很容易于理解与使用；

2.安全：没有涉及到用户密钥等信息，更安全更灵活；

3.开放：任何服务提供商都可以实现OAuth，任何软件开发商都可以使用OAuth；

OAuth

2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0，即完全废止了OAuth 1.0。OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749。

2.3.3.1授权流程

OAuth

2.0的流程如下：

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

2.3.3.2四大角色

由授权流程图中可以看到OAuth 2.0有四个角色：客户端、资源拥有者、资源服务器、授权服务器。

1.客户端：客户端是代表资源所有者对资源服务器发出访问受保护资源请求的应用程序。

2.资源拥有者：资源拥有者是对资源具有授权能力的人。

3.资源服务器：资源所在的服务器。

4.授权服务器：为客户端应用程序提供不同的Token，可以和资源服务器在统一服务器上，也可以独立出去。

2.3.3.3客户端的授权模式

客户端必须得到用户的授权（Authorization Grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式：authorizationcode、implicit、resource owner password credentials、client credentials。

1.授权码模式（authorization code）

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。流程如下：

1)用户访问客户端，后者将前者导向认证服务器。

2)用户选择是否给予客户端授权。

3)假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection

URI），同时附上一个授权码。

4)客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

5)认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

2.简化模式（implicit）

简化模式（Implicit Grant Type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。流程如下：

1)客户端将用户导向认证服务器。

2)用户决定是否给于客户端授权。

3)假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

4)浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

5)资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。

6)浏览器执行上一步获得的脚本，提取出令牌。

7)浏览器将令牌发给客户端。

3.密码模式（Resource Owner Password Credentials）

密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。流程如下：

1)用户向客户端提供用户名和密码。

2)客户端将用户名和密码发给认证服务器，向后者请求令牌。

3)认证服务器确认无误后，向客户端提供访问令牌。

4.客户端模式（Client Credentials）

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。

在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。流程如下：

1)客户端向认证服务器进行身份认证，并要求一个访问令牌。

2)认证服务器确认无误后，向客户端提供访问令牌。

2.3.4思考总结

正如David Borsos所建议的一种方案，在微服务架构下，我们更倾向于将Oauth和JWT结合使用，Oauth一般用于第三方接入的场景，管理对外的权限，所以比较适合和API网关结合，针对于外部的访问进行鉴权（当然，底层Token标准采用JWT也是可以的）。JWT更加轻巧，在微服务之间进行访问鉴权已然足够，并且可以避免在流转过程中和身份认证服务打交道。当然，从能力实现角度来说，类似于分布式Session在很多场景下也是完全能满足需求，具体怎么去选择鉴权方案，还是要结合实际的需求来。

3.如何进行容量设计

3

3.1需求缘起

互联网公司，这样的场景是否似曾相识：

场景一：pm要做一个很大的运营活动，技术老大杀过来，问了两个问题：

（1）机器能抗住么？

（2）如果扛不住，需要加多少台机器？

场景二：系统设计阶段，技术老大杀过来，又问了两个问题：

（1）数据库需要分库么？

（2）如果需要分库，需要分几个库？

技术上来说，这些都是系统容量预估的问题，容量设计是架构师必备的技能之一。常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等，今天分享的内容，就以【并发量】为例，看看如何回答好这两个问题。

3.2容量评估的步骤与方法

【步骤一：评估总访问量】

如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？

答案是：询问业务方，询问运营同学，询问产品同学，看对运营活动或者产品上线后的预期是什么。

举例：58要做一个APP-push的运营活动，计划在30分钟内完成5000w用户的push推送，预计push消息点击率10%，求push落地页系统的总访问量？

回答：5000w*10% = 500w

【步骤二：评估平均访问量QPS】

如何知道平均访问量QPS？

答案是：有了总量，除以总时间即可，如果按照天评估，一天按照4w秒计算。

举例1：push落地页系统30分钟的总访问量是500w，求平均访问量QPS

回答：500w/(30*60) = 2778，大概3000QPS

举例2：主站首页估计日均pv 8000w，求平均访问QPS

回答：一天按照4w秒算，8000w/4w=2000，大概2000QPS

提问：为什么一天按照4w秒计算？

回答：一天共24小时*60分钟*60秒=8w秒，一般假设所有请求都发生在白天，所以一般来说一天只按照4w秒评估

【步骤三：评估高峰QPS】

系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢？

答案是：根据业务特性，通过业务访问曲线评估

举例：日均QPS为2000，业务访问趋势图如下图，求峰值QPS预估？

回答：从图中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS为2000，于是评估出峰值QPS为5000。

说明：有一些业务例如“秒杀业务”比较难画出业务访问趋势图，这类业务的容量评估不在此列。

【步骤四：评估系统、单机极限QPS】

如何评估一个业务，一个服务单机能的极限QPS呢？

答案是：压力测试

在一个服务上线前，一般来说是需要进行压力测试的（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP-push运营活动落地页为例（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：

1）访问端是APP

2）运营活动H5落地页是一个web站点

3）H5落地页由缓存cache、数据库db中的数据拼装而成

通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS（一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈），我们就得到了web单机极限的QPS是1200。一般来说，线上系统是不会跑满到极限的，打个8折，单机线上允许跑到QPS1000。

【步骤五：根据线上冗余度回答两个问题】

好了，上述步骤1-4已经得到了峰值QPS是5000，单机QPS是1000，假设线上部署了2台服务，就能自信自如的回答技术老大提出的问题了：

（1）机器能抗住么？->峰值5000，单机1000，线上2台，扛不住

（2）如果扛不住，需要加多少台机器？->需要额外3台，提前预留1台更好，给4台更稳

除了并发量的容量预估，数据量、带宽、CPU/MEM/DISK等评估亦可遵循类似的步骤。

3.3总结

互联网架构设计如何进行容量评估：

【步骤一：评估总访问量】->询问业务、产品、运营

【步骤二：评估平均访问量QPS】->除以时间，一天算4w秒

【步骤三：评估高峰QPS】->根据业务曲线图来

【步骤四：评估系统、单机极限QPS】->压测很重要

【步骤五：根据线上冗余度回答两个问题】->估计冗余度与线上冗余度差值