性能（performance）-> 响应时间： 接口请求的响应时间可伸缩性（Scalability）： 包括横向扩展（Scaling Out）和纵向扩展（Scaling Up ）横向扩展（水平扩展）： 增加实例、增加机器纵向扩展（垂直扩展）： 增加硬件配置如 CPU 核数；使用更高性能的 CPU、网卡等；增加内存容量；

但是这里需要注意的是响应时间 和 可伸缩性可能不是同步的或者是线性的，也就是说当请求量增加，并且进行各种扩容后，虽然抗住了请求量，但是响应时间不见得会变短，可能会变长，因为请求量的增加导致底层的各种系统资源消耗较多或者下游的依赖压力较大从而导致响应时间变长。

系统资源 和 水平扩展的关系

请求量增加的时候，要进行扩容，扩容最容易和最常见的方式是水平扩展服务，也就是扩容无状态实例。但是，针对一些系统资源或者依赖资源，比如数据库（MySQL）、缓存（Redis）等，这些有状态的不能无限扩容，因此就一定考虑他们的性能，他们的性能才是底线，如果 redis 、ES 等扛不住，那么扩容再多无状态实例也是白费。这里需要特别注意这些底层依赖资源的性能以及无状态服务和他们连接的一些连接池、并发数等。

可扩展和 弹性伸缩的关系

可扩展性是指系统适应更大的负载的能力，只需通过增加资源，使硬件更强大（扩展）或增加额外的节点（扩展）。

弹性伸缩是指动态地适应应对负载所需的资源的能力，通常与扩展性有关。因此，当负载增加时，你通过添加更多的资源来扩大规模，而当需求减弱时，你就缩减并删除不需要的资源。 弹性伸缩在云环境中非常重要，一方面你要按使用量付费，不想为你目前不需要的资源付费，另一方面要在需要时满足不断增长的需求。

可扩展架构设计（Scalability）

可扩展架构设计的最佳实践

一些最佳实践可以参考（翻译） OpenShift 的 Best Practices for Scaling Out 这篇文章，这里在此基础上做进一步的整理和总结：

微服务化设计，尽量让我们的系统模块化、组件化，从而实现高内聚，低耦合的思想，提高复用性，扩展性。这样每个微服务可以独立进行扩展，而且一个服务挂掉并不会导致整个服务不可用；这个也同样适用于数据库的拆分逻辑。分层设计，可扩展架构设计的基本要求就是我们服务要先进行分层，然后每一层都要能够单独扩展，并且需要用到负载均衡技术。消息队列：模块化的系统通过消息队列进行交互，使模块之间的依赖解耦。队列的引入可以缓解流量突峰，也可以流程异步化，提高性能、稳定性。 高并发、大流量下，同步机制会使得整体响应非常慢，因此当前一般的高并发系统都是异步处理的，一般我们可以通过消息队列实现异步。分布式服务：公用模块服务化，提供其他系统使用，提高可重用性，扩展性。联系紧密的服务尽量部署到同一个集群，避免跨集群访问带来的延迟、带宽增加等应用程序应该尽量采用无状态服务，而不是采用有状态服务；将需要存储的状态统一用分布式存储、分布式缓存来存储。善用分布式缓存；访问缓存比访问数据库或者文件系统性能高很多，避免直接操作数据库，可以极大提高性能设计模式：应用面向对象思想，原则，使用设计模式，进行代码层面的设计。网关入口要使用负载均衡层，常见的是 Nginx 和 HAProxy，当做 7 层代理集群，然后后面再接入应用服务。使用代理层是可扩展架构的必要前提。不要过度设计，根据情况考虑是否最初就设计为可扩展架构，不必从一开始就构建可伸缩的体系结构，扩展的关键是先于用户发现瓶颈。不要强迫将自己熟知的技术运用到不恰当的领域来解决特定领域的问题；所用来解决问题的技术方案应该是某个技术所擅长的领域尽可能的自动化所有事情，好的监控统计系统非常重要，可以帮助我们了解系统的运行状态、回溯问题、分析问题；及时告警，这个不仅仅是针对扩展架构，所有服务架构都是一样的。

可扩展代码的一些最佳实践

参考（翻译）Rackspace Writing Code that Scales 的写出高扩展和高性能代码的工程原则：