开发Java Web程序

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内联。