架构师学习条例:【译】可伸缩性最佳实践

xjb

下面是我们认为的一些可伸缩性的最佳实践：
1、异步；尽可能的使用异步，同步调用会导致两个服务的可用性绑在一起，意味着一个服务出问题或变慢，另一个也会受到影响，这点也是eBay一直强调的；

2、泳道设计；错误隔离机制，避免一个失败影响全局，这种机制也有助于错误查找和代码替换；

3、缓存；在所有层次均使用缓存，例如数据、页面、页面片段等；

4、监测；从用户角度来看系统的性能。这包括从外部网络来对系统进行性能的监测，以及内部的系统间交互次数以及时间的监测；

5、数据复制；一方面是为了容灾，另一方面是为了提供多个用于读的数据库，降低写库的压力；

6、拆分；包括了应用的拆分以及数据库的拆分；

7、尽量少的使用数据库特性；尽可能的把数据库仅作为一个在线存储的功能而使用，不要把业务逻辑放在数据库里，否则将来会非常难扩展；

8、缓慢发布；发布时应缓慢发布，以保证新版本是正常的，避免由于某个压力测试时没测到的点，导致全站出问题；

9、压力以及性能测试；在发布前测试性能，尽管这不一定能发现全部问题，因此在发布前仍然要做好回滚的方案；

10、容量规划；提前判断系统能支撑多大的量，并做好扩容计划；

11、回滚；每次都要做好回滚的准备；

12、根源分析；确认有办法找到线上问题的根源所在，从而能够真正的解决问题；

13、从一开始就要注重质量；质量不能仅靠测试来保证，必须从设计阶段开始就去保证。

xjb

http://akfpartners.com/techblog/2009/08/11/scalability-best-practices/

• Asynchronous - Use asynchronous communication when possible. Synchronous calls tie the availability of the two services together. If one has a failure or is slow the other one is affected.
• Swim Lanes – Create fault isolated “swim lanes” of hardware by customer segmentation. This prevents problems with one customer from causing issues across all customers. This also helps with diagnosis of issues and code roll outs.
• Cache - Make use of cache at multiple layers including object caches in front of databases (such as memcached), page or item caches for content (such as squid) and edge caches (such as Akamai).
• Monitoring - Understand your application’s performance from a customer’s perspective. Monitor outside of your network and have tests that simulate a real user’s experience. Also monitor the internal working of the application in terms of query and transaction execution count and timing.
• Replication - Replicate databases for recovery as well as to off load reads to multiple instances.
• Sharding - Split the application and databases by service and / or by customer using a modulus. While this requires slightly more complicated logic in the application it allows for massive scaling.
• Use Few RDBMS Features – Use the OLTP database as a persistent storage device as much as possible. The more you rely on the features offered in most RDBMS for your transactions, the greater load you are putting on the hardest item in your system to scale. Remove all business logic from the database such as stored procedures and move it into the application. When significant scaling is required join in the application and not through the SQL.
• Slow Roll – Roll out new code versions slowly, to a small subset of your servers without bringing the entire site down. This requires that all code be backwards compatible because you will have two versions of code running in production during the roll out. This method allows you to find problems that your quality and L&P testing missed while having minimal impact on customers.
• Load & Performance Testing – Test the performance of the application version before it goes into production. This will not catch all the issues, which is why you need the ability to rollback, but it is very worthwhile.
• Capacity Planning / Scalability Summits – Know how much capacity you have on all tiers and services in your system. UseScalability Summits to plan for the increased capacity demands.
• Rollback – Always have the ability to rollback a code release.
• Root Cause Analysis - Ensure you have a learning culture that is evident by utilizing Root Cause Analysis to find and fix the real cause of issues.
• Quality From The Beginning – Quality can’t be tested into a product, it must be designed in from the beginning.