要学好分布式架构，你首先需要学习一些架构指导性的文章和方法论，即分布式架构设计原则。下面是几篇很不错的文章，值得一读。
Designs, Lessons and Advice from Building Large Distributed Systems，Google 杰夫·迪恩（Jeff Dean）2009年一次演讲的PPT。2010年，斯坦福大学请杰夫·迪恩到大学里给他们讲了一节课，你可以在YouTube上看一下，Building Software Systems At Google and Lessons Learned ，其回顾了Google发展的历史。
The Twelve-Factor App ，如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建SaaS应用提供了方法论，是架构师必读的文章。（中译版）这篇文章在业内的影响力很大，必读！
Notes on Distributed Systems for Young Bloods ，给准备进入分布式系统领域的人的一些忠告。
On Designing and Deploying Internet-Scale Services（中译版），微软Windows Live服务平台的一些经验性的总结文章，很值得一读。
4 Things to Keep in Mind When Building a Platform for the Enterprise ，Box平台VP海蒂·威廉姆斯（Heidi Williams）撰写的一篇文章，阐述了为企业构建平台时需要牢记的四件关于软件设计方面的事：1. Design Broadly, Build Narrowly； 2. Platforms Are Powerful and Flexible. Choose wisely what to expose when!；3. Build Incrementally, Get Feedback, and Iterate；4. Create a Platform-first Mentality。文章中有详细的解读，推荐看看。
Principles of Chaos Engineering ，我们知道，Netflix公司有一个叫Chaos Monkey的东西，这个东西会到分布式系统里“瞎搞”，以此来测试系统的健壮和稳定性。这个视频中，Netflix分享了一些软件架构的经验和原则，值得一看。
Building Fast & Resilient Web Applications ，伊利亚·格里高利克（Ilya Grigorik）在Google I/O 2016上的一次关于如何通过弹力设计来实现快速和可容错的网站架构的演讲，其中有好些经验分享。
Design for Resiliency ，这篇文章带我们全面认识“弹力（Resiliency）”，以及弹力对于系统的重要性，并详细阐述了如何设计和实现系统的弹力。
微软的Azure网站上有一系列的 Design Principle 的文章，你可以看看这几篇： Design for Self-healing 、Design for Scaling Out 和 Design for Evolution 。
Eventually Consistent ，AWS CTO维尔纳·沃格尔斯（Werner Vogels）发布在自己Blog上的一篇关于最终一致性的好文。
Writing Code that Scales ，Rackspace的一篇很不错的博文，告诉我们一些很不错的写出高扩展和高性能代码的工程原则。
Automate and Abstract: Lessons from Facebook on Engineering for Scale ，软件自动化和软件抽象，这是软件工程中最重要的两件事了。通过这篇文章，我们可以看到Facebook的关于这方面的一些经验教训。
有了方法论后，你还需要学习一些比较细节的落地的技术。最好的方式就是学习被前人总结出来的设计模式，虽然设计模式也要分场景，但是设计模式可以让你知道一些套路，这些套路对于我们设计的分布式系统有非常大的帮助，不但可以让我们少走一些弯路，而且还能让我们更为系统和健壮地设计我们的架构。
下面是一些分布式架构设计模式的网站。
首先，需要重点推荐的是微软云平台 Azure 上的设计模式。 Cloud Design Patterns ，这个网站上罗列了分布式设计的各种设计模式，可以说是非常全面和完整。对于每一个模式都有详细的说明，并有对其优缺点的讨论，以及适用场景和不适用场景的说明，实在是一个非常不错的学习分布式设计模式的地方。其中有如下分类。
除此之外，还有其它的一些关于分布式系统设计模式的网站和相关资料。
AWS Cloud Pattern ，这里收集了AWS云平台的一些设计模式。
Design patterns for container-based distributed systems ，这是Google给的一篇论文，其中描述了容器化下的分布式架构的设计模式。
Patterns for distributed systems ，这是一个PPT，其中讲了一些分布式系统的架构模式，你可以顺着到Google里去搜索。
我个人觉得微服务也好，SOA也好，都是分布式系统的一部分，这里有两个网站罗列了各种各样的服务架构模式。
当然，还有我在极客时间上写的那些分布式的设计模式的总结。
弹力设计篇，内容包括：认识故障和弹力设计、隔离设计、异步通讯设计、幂等性设计、服务的状态、补偿事务、重试设计、熔断设计、限流设计、降级设计、弹力设计总结。
管理设计篇，内容包括：分布式锁、配置中心、边车模式、服务网格、网关模式、部署升级策略等。
性能设计篇，内容包括：缓存、异步处理、数据库扩展、秒杀、边缘计算等。
FIT: Failure Injection Testing ，Netflix公司的一篇关于做故障注入测试的文章。
Automated Failure Testing ，同样来自Netflix公司的自动化故障测试的一篇博文。
Automating Failure Testing Research at Internet Scale ，Netflix公司伙同圣克鲁斯加利福尼亚大学和Gremlin游戏公司一同撰写的一篇论文。
4 Architecture Issues When Scaling Web Applications: Bottlenecks, Database, CPU, IO ，本文讲解了后端程序的主要性能指标，即响应时间和可伸缩性这两者如何能提高的解决方案，讨论了包括纵向和横向扩展，可伸缩架构、负载均衡、数据库的伸缩、CPU密集型和I/O密集型程序的考量等。
Scaling Stateful Objects ，这是一本叫《Development&Deployment of Multiplayer Online Games》书中一章内容的节选，讨论了有状态和无状态的节点如何伸缩的问题。虽然还没有写完，但是可以给你一些很不错的基本概念和想法。
Scale Up vs Scale Out: Hidden Costs ，Coding Horror上的一篇有趣的文章，详细分析了可伸缩性架构的不同扩展方案（横向扩展或纵向扩展）所带来的成本差异，帮助你更好地选择合理的扩展方案，可以看看。
Best Practices for Scaling Out ，OpenShift的一篇讨论Scale out最佳实践的文章。
Scalability Worst Practices ，这篇文章讨论了一些最差实践，你需要小心避免。
Reddit: Lessons Learned From Mistakes Made Scaling To 1 Billion Pageviews A Month ，Reddit分享的一些关于系统扩展的经验教训。
下面是几篇关于自动化弹性伸缩的文章。
Consistent Hashing ，这是一个一致性哈希的简单教程，其中还有代码示例。
Consistent Hashing: Algorithmic Tradeoffs ，这篇文章讲述了一致性哈希的一些缺陷和坑，以及各种哈希算法的性能比较，最后还给了一组代码仓库，其中有各种哈希算法的实现。
Distributing Content to Open Connect ，Netflix的一个对一致性哈希的实践，提出了Uniform Consistent Hashing，是挺有意思的一篇文章。
Consistent Hashing in Cassandra ，这是Cassandra中使用到的一致性哈希的相关设计。
Life Beyond Distributed Transactions ，该文是Salesforce的软件架构师帕特·赫兰德（Pat Helland）于2016年12月发表的针对其在2007年CIDR（创新数据库研究会议）上首次发表的同名文章的更新和缩写版本。业界谈到分布式事务通常指两段提交2PC事务（Spring/JEE中JTA等)或者Paxos与Raft，这些事务都有明显缺点和局限性。
而赫兰德在本文讨论的是另外一种基于本地事务情况下的事务机制，它是基于实体和活动（Activity）的概念，其实类似DDD聚合根和领域事件的概念，这种工作流类型事务虽然需要程序员介入，依靠消息系统实现，但可以实现接近无限扩展的大型系统。赫兰德文中提出了重要的观点：“如果你不能使用分布式事务，那么你就只能使用工作流。”
How Sharding Works ，这是一篇很不错的探讨数据Sharding的文章。基本上来说，数据Sharding可能的问题都在这篇文章里谈到了。
Why you don’t want to shard ，这是Percona的一篇文章，其中表达了，不到万不得已不要做数据库分片。是的，最好还是先按业务来拆分，先把做成微服务的架构，然后把数据集变简单，然后再做Sharding会更好。
How to Scale Big Data Applications ，这也是Percona给出的一篇关于怎样给大数据应用做架构扩展的文章。值得一读。
MySQL Sharding with ProxySQL ，用ProxySQL来支撑MySQL数据分片的一篇实践文章。
缓存更新的套路，这是我在CoolShell上写的缓存更新的几个设计模式，包括Cache Aside、Read/Write Through、Write Behind Caching。
Design Of A Modern Cache ，设计一个现代化的缓存系统需要注意到的东西。
Netflix: Caching for a Global Netflix ，Netflix公司的全局缓存架构实践。
Facebook: An analysis of Facebook photo caching ，Facebook公司的图片缓存使用分析，这篇文章挺有意思的，用数据来调优不同的缓存大小和算法。
How trivago Reduced Memcached Memory Usage by 50% ，Trivago公司一篇分享自己是如何把Memcached的内存使用率降了一半的实践性文章。很有意思，可以让你学到很多东西。
Caching Internal Service Calls at Yelp ，Yelp公司的缓存系统架构。
Understanding When to use RabbitMQ or Apache Kafka ，什么时候使用RabbitMQ，什么时候使用Kafka，通过这篇文章可以让你明白如何做技术决策。
Trello: Why We Chose Kafka For The Trello Socket Architecture ，Trello的Kafka架构分享。
LinkedIn: Running Kafka At Scale ，LinkedIn公司的Kafka架构扩展实践。
Should You Put Several Event Types in the Same Kafka Topic? ，这个问题可能经常困扰你，这篇文章可以为你找到答案。
Billions of Messages a Day - Yelp’s Real-time Data Pipeline ，Yelp公司每天十亿级实时消息的架构。
Uber: Building Reliable Reprocessing and Dead Letter Queues with Kafka ，Uber公司的Kafka应用。
Uber: Introducing Chaperone: How Uber Engineering Audits Kafka End-to-End ，Uber公司对Kafka消息的端到端审计。
Publishing with Apache Kafka at The New York Times ，纽约时报的Kafka工程实践。
Kafka Streams on Heroku ，Heroku公司的Kafka Streams实践。
Salesforce: How Apache Kafka Inspired Our Platform Events Architecture ，Salesforce的Kafka工程实践。
Exactly-once Semantics are Possible: Here’s How Kafka Does it ，怎样用Kafka让只发送一次的语义变为可能。这是业界中一个很难的工程问题。
Delivering billions of messages exactly once 同上，这也是一篇挑战消息只发送一次这个技术难题的文章。
Benchmarking Streaming Computation Engines at Yahoo!。Yahoo!的Storm团队在为他们的流式计算做技术选型时，发现市面上缺乏针对不同计算平台的性能基准测试。于是，他们研究并设计了一种方案来做基准测试，测试了Apache Flink、Apache Storm和Apache Spark这三种平台。文中给出了结论和具体的测试方案。（如果原文链接不可用，请尝试搜索引擎对该网页的快照。）
Using Logs to Build a Solid Data Infrastructure - Martin Kleppmann ，设计基于log结构应用架构的一篇不错的文章。
Building DistributedLog: High-performance replicated log service ，Distributed是Twitter 2016年5月份开源的一个分布式日志系统。在Twitter内部已经使用2年多。其主页在 distributedlog.io。这篇文章讲述了这个高性能日志系统的一些技术细节。另外，其技术负责人是个中国人，其在微信公众号中也分享过这个系统 Twitter高性能分布式日志系统架构解析。
LogDevice: a distributed data store for logs ，Facebook分布式日志系统方面的一些工程分享。
Understand Latency ，这篇文章收集并整理了一些和系统响应时间相关的文章，可以让你全面了解和Latency有关的系统架构和设计经验方面的知识。
Common Bottlenecks ，文中讲述了20个常见的系统瓶颈。
Performance is a Feature ，Coding Horror上的一篇让你关注性能的文章。
Make Performance Part of Your Workflow ，这篇文章是图书《Designing for Performance》中的节选（国内没有卖的），其中给出来了一些和性能有关的设计上的平衡和美学。
CloudFlare: How we built rate limiting capable of scaling to millions of domains，讲述了CloudFlare公司是怎样实现他们的限流功能的。从最简单的每客户IP限流开始分析，进一步讲到anycast，在这种情况下PoP的分布式限流是怎样实现的，并详细解释了具体的算法。
High Scalability ，这个网站会定期分享一些大规模系统架构是怎样构建的，下面是迄今为止各个公司的架构说明。
今天我们分享的内容是高手成长篇分布式架构部分的最后一篇——分布式架构工程设计，讲述了设计原则、设计模式等方面的内容，尤其整理和推荐了国内外知名企业的设计思路和工程实践，十分具有借鉴意义。
下篇文章中，我们将分享微服务架构方面的内容。敬请期待。
下面是《程序员练级攻略》系列文章的目录。
评论