1. 考虑使用不止一个数据中心
在商务领域，一直存在许多恐怖的道听途说，而这些恐慌都因为他们只使用了单一的数据中心。如果你想在自然灾害或者电力供应故障中幸免，那么请使用多于1个的数据中心，使用active-active模式来配置你所有的数据中心。虽然在开销上可能会有所增加，但是比只使用单active的配置要值得多——因为在passive和active副本上，总会发现有些数据片不一致。
2. 考虑使用稀疏数据中心部署
不管是通过PaSS，还是运营团队进行，当软件集群被部署到同一个数据中心的机架上时，确保这些机架使用不同的电力供应。你不可能保证机架供电的万无一失，一旦失败将会导致整个机架上服务器的丢失，这个时候你绝对不会希望整个数据中心都只连在一个电路上。
3. 考虑使用私有云来组织资源
IaaS开源解决方案Openstack等其他的软件至今尚未成熟，需要庞大的团队来运营，在运行期间会产生各种各样的问题，除非你有足够的预算，否则别考虑建立一个私有的云服务。然而，私有云可以提供众多优势。首先在部署方面就可以进行众多的定制化，这远比AWS或者是Rackspace货架上的选择要多。其次它允许你做许多的硬件定制化，就好比在硬件层次的Oracle就比准虚拟化环境快得多。
4. 考虑使用PaaS做解决方案
为软件释放投入巨量人力进行部署的日子已接近尽头，各个机构在敏捷及快速市场投放上绞尽脑汁，而PaaS无疑会加速这个部署过程。它允许特性尽可能快的发布，同时也能让开发者得到极大的满足。这是个非常好的开始，给予开发者部署集维护自己软件的工具，这将给工作积极性带来很大的提高。同时，越来越多的开发者甚至不愿意加入没有自动化软件部署系统的公司。更少的领导，更简化的环节，将给你带来无与伦比的效率。
5. 如果使用Oracle或者MySQL，只做基于主键的查询
只有在RAC中存在很少的Artifacts时，Oracle才能在流量高峰时获得最佳性能。尽可能避免使用Referential Integrity、Triggers、Materialized Views、Views、Stored Procedures和其他的Oracle Artifacts。Triggers可以在从数据访问层实现。Stored Procedures可以完全转移到应用层。数据库只用来存储数据，基于字段进行存储而不是主键，使用类似Lucene的索引器做表的索引，使用一个允许在结果集上做基于其他字段的查询，这将会返回这个记录的主键，而这个主关键字可以进一步被用来拿取记录。
6. 考虑使用Oracle或者MySQL分片
当schema达到临界点，Oracle的可伸缩性将被限制，这里建议你对schema做基于功能（比如订单，产品目录，促销活动，客户等）上的分片，同时也为高密度表做key shards。为key shards使用一致性哈希，这样当一个新的RAC被添加RAC集时，你不再需要遍历所有RAC中的键，以获悉哪些键需要被移动到键的分片中。
7. 如果你使用Oracle做RDBMS，考虑使用Data Guard及Golden Gate
使用这两种技术将大大简化甲骨文的运营周期，Data Guard允许一个近实时passive读副本（没有客户端会与之连接），而Golden Gate则允许一个近实时的active读写副本。
推荐的部署拓扑之一就是为同个数据中心的每个分片配置1个Data Guard；使用Golden Gate来备份其他数据中心的每一个分片。
注意：Golden Gate只是近实时
8. 为Oracle或者MySQL添加数据访问层
假设你有一个可以接受500个连接的Oracle RAC，而你有25个jBoss实例和这个甲骨文RAC对话，每个Jboss实例配置范围10到50的数据库连接池。
当jBoss集群开启时，连接到Oracle的数目为250（25乘10），一切运行良好。随着流量快到jBoss集群的峰值，想象一下将会发生什么。在某个点后，Oracle将开始拒绝连接。
因此建议通过一个Multiplexer层建立一个Multiplexe应用程序服务器连接。可以是一个简单的 netty应用，这个应用运行在一个每个netty节点仅能够与Oracle建立25个连接的集群上，但是对入站连接来者不拒。它会将所有的连接循环传递给Oracle，但是绝对不会超过25个，同时还使用Oracle JDBC驱动与Oracle通信。
9. 避免跨数据中心事务
当下，这已经是非常简单的事情，但是在任何地方都非常适用，包括Oracle。在两个数据不同数据中心，不要适用1个XA适配器去做跨数据中心事务，这将导致相当长时间的应用线程阻塞，直到两个阶段的提交完成，因此将带来你的应用程序服务、服务和所有同步上传流崩溃，最终会因为线程数量增加而导致整个应用程序崩溃，比如在类似Black Friday流量情况下。
10. 考虑分布式缓存框架
Memcached、Counbase是最常用的选择。但实际上，卸载非易失性数据到一个中心缓存集群上，确实没必要在每个JVM上做相同的拷贝。但是确实需要设置小数量的JVM堆作为分布式缓存的一个MRU缓存，这样的话，缓存集群本身将会受到非常少的网络调用。
- 在JVM上大多数分布式缓存支持本地缓存的概念，它将储存最常用的对象。
- JVM上，GC的pause time同样被最小化了，因为对象图中需要遍历的对象比以前更少了。
- Warmup过程是必不可少的，这可以帮助将数据导入分布式缓存，这个过程应该在晚上或者是用户访问量低的时候。
11. 考虑把web应用程序分解为服务
上帝保佑，如果你负责的web应用程序超过50万行代码，而且仍然只作单一的项目部署，那么是时候根据服务功能把它分解成专业的服务了，并分配到不同的子组织或团队去操作。将Web应用程序分解为服务有以下诸多优势：
- Debug将变得简单
- 扩展及让子系统运行的更好将变得简单
- 很容易了解运行环境里发生了什么
- 更快的添加新功能
12. 不要使用session stickiness
这绝是与魔鬼共舞，session stickiness会让极值负荷下无法扩展。你的客户端应该能够调用ANY应用程序服务器，并得到其查询值。其中一个方法是让服务无状态，也称为RestFUL服务。每个请求，客户端会收发标识状态的id，代表客户session的数据存储在数据库或跨多个请求的分布式缓存。
如果因为某个原因，取代RestFUL服务，你网站大部分是建立在HttpServlets和HttpSession属性上，使用以下方法可以实现独立session stickiness的网站：
一个servlet过滤器面对每项服务，取走每个请求的id，然后调用分布式缓存来填充会话属性，这将有助于处理请求。因此数据中心任何服务器都可以响应来自客户端的请求，因为session状态被保持在memcached。
不使用session stickiness还允许使用“rolling restart”方式重启你的应用程序服务器集群，从而实现100%的正常运行时间。
13. 终止反向代理商的SSL
在SSL信号交换及潜在TCP通信有效保持上，反向代理非常擅长。在反向代理有上设定一个显式的TCP维持计时器，nGinx及许多其他http服务器都允许这么做，这允许TCP连接多次重复使用。与TCP信号交换的成本是3个network call，这样许多请求就可以避免这个开销。
因此从反向代理到应用程序服务器，通常是RAW http；因此，同样也要维持TCP的上行连接。
14. 为GSLB类型的负载平衡器使用粘性负载平衡
跨数据中心的负载平衡，建议使用session stickiness。这是因为在跨数据中心复制上，数据库Oracle或Cassandra只能依赖最终一致性技术。因此，非粘性跨数据中心负载均衡器将使你的客户端再也无法访问网站。因此经常使用GSLB，多数情况下，你的CDN将获得基于位置的GSLB数据中心解决方案。
15. 减少主页上的CNAME查找
尽量减少主页上的CNAME查找。单单主页的CNAME查找，一些网站就有10个或更多。即使客户端DNS查找的答案可能来自他们的ISP递归缓存，我们仍然可以做的更好。www.amazon.com CNAME查找为零。
dig
www.amazon.com
;; QUESTION SECTION:
;www.amazon.com. IN A
;; ANSWER SECTION:
www.amazon.com.28 IN A 205.251.242.54
16. 拥抱一切“reactor”
在高流量软件系统中，reactor模式一次又一次的得以证明。一系列框架被创建用以实现reactor模式，reactor大致使用场景如下：
- 作为一个反向代理:nGinx
- 应用程序服务器: node.js
- 并行处理的: Scala的actor model
除非你的业务逻辑是高度CPU绑定，否则就得考虑使用reactor模式或基于事件循环的软件。如果无法实现，可以考虑像RxJava框架那样的响应式编程模型。
17. 实现调用取消
从Siddharth Anand的一个会议上得到灵感，服务调用时的调用图。首先，通过数字的递减实现超时。接下来，服务调用图的每次调用，都会创建一个UUID，并在分布式缓存中为UUID设置一个标志：
UUID：true
- 如果服务调用图中的任何服务超时，UUID的标志设置为false。
- 现在为所有服务实现一个servlet过滤器，一直检查这个标志，只在这个标志是真时才继续处理。
- 如果标志是是假，程序返回一个空的response。
- 这在大业务量时，可以禁止不必要的调用。
18. 执行GC搜索协议
再次，灵感来自于同一个人——通过Netty让所有的服务也显示一个TCP端口。在调用一个服务之前，调用TCP端口然后暂停2 - 5 ms等待访问。如果调用超时，这意味着这个Java进程正字做一个“stop the world”的垃圾收集。客户立即切换到另一个服务实例，然后尝试同样的步骤。如果调用成功，然后调用实例上的实际服务。
注意：实现GC搜索协议需要的客户端ip地址配置（即客户端负载均衡）。
19. 尽可能让业务逻辑和I / O存取异步进行
在流量爆炸时，异步业务逻辑能让您的应用程序避免建立过多的线程。将事件队列推送给负载均衡集群，让它去做进程订阅的业务逻辑，而不是在http request/response周期线程做这些事。
20. 偏爱最终一致性数据库
尤其是当你在运行跨数据中心的应用程序。除非你的用例是事务处理的（比如订单）等等，否则偏爱使用最终一致性数据库比如Cassandra，并尽可能少的使用ACID类型数据库。
21. 使用CDN服务静态内容
使用CDN服务静态内容——Javascript、图像、css 等。CDN能有效地将静态内容复制到近客户地方，因此许多针对这些静态内容的http请求最终穿越不会超过几百英里。
22. 打包压缩Javascript到一个文件中
减少Javascript内联。
注意：不要在pre-prod环境中这么做，这里需要使用调试程序做Javascript的debug。
京公网安备 11010802041100号