1. 考虑使用不止一个数据中心

在商务领域,一直存在许多恐怖的道听途说,而这些恐慌都因为他们只使用了单一的数据中心。如果你想在自然灾害或者电力供应故障中幸免,那么请使用多于1个的数据中心,使用active-active模式来配置你所有的数据中心。虽然在开销上可能会有所增加,但是比只使用单active的配置要值得多——因为在passive和active副本上,总会发现有些数据片不一致。

2. 考虑使用稀疏数据中心部署

不管是通过PaaS,还是运营团队进行,当软件集群被部署到同一个数据中心的机架上时,确保这些机架使用不同的电力供应。你不可能保证机架供电的万无一失,一旦失败将会导致整个机架上服务器的丢失,这个时候你绝对不会希望整个数据中心都只连在一个电路上。

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.dwhao.com CNAME查找为零。

dig www.dwhao.com  
;; QUESTION SECTION: 
;www.dwhao.com IN A 
;; ANSWER SECTION: 
www.dwhao.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”的垃圾收集。重生之大文豪www.dwhao.com客户立即切换到另一个服务实例,然后尝试同样的步骤。如果调用成功,然后调用实例上的实际服务。

注意:实现GC搜索协议需要的客户端ip地址配置(即客户端负载均衡)。

19. 尽可能让业务逻辑和I / O存取异步进行

在流量爆炸时,异步业务逻辑能让您的应用程序避免建立过多的线程。将事件队列推送给负载均衡集群,让它去做进程订阅的业务逻辑,而不是在http request/response周期线程做这些事。

20. 偏爱最终一致性数据库

尤其是当你在运行跨数据中心的应用程序。除非你的用例是事务处理的(比如订单)等等,否则偏爱使用最终一致性数据库比如Cassandra,并尽可能少的使用ACID类型数据库。

21. 使用CDN服务静态内容

使用CDN服务静态内容——javascript、图像、css 等。CDN能有效地将静态内容复制到近客户地方,因此许多针对这些静态内容的http请求最终穿越不会超过几百英里。 

22. 打包压缩javascript到一个文件中

减少javascript内联。