文章：可伸缩性最佳实践──来自 eBay 的经验

单体到微服务是一个演化过程，别在一开始就过度设计

在Reactive Summit 2018大会上，Randy Shoup在演讲中分享了他与小公司一起，逐步发展成为大型全球性互联网公司的经验，以及它们的架构是如何进行演变的，并从IT专业的角度为创办新公司或推出新产品提出了一些建议。

总体架构设计

如何设计列表页的阅读顺序？

醒醒！你不是真的需要微服务

2020 年，很多技术人可能都已经迷醉在了微服务的成功故事中，但现实很骨感，微服务也不是“灵丹妙药”。本文想给现阶段“狂热”的微服务泼泼冷水、降降温，也许你就会发现，你并不是真的需要微服务。

开发运维视角下，影响软件高可扩展性的 6 个因素

软件可扩展性的实现涉及很多因素，本文讨论了一些与开发和运维方面相关的因素。

架构师 1 期第三周总结

这周总体时间偏紧，感觉前两天课程打算十一放假，后来又放了出来，这周看老师拿着程序讲架构还是第一次，感觉在讲到一个不好的程序，老师逐步拆分的时候，收获挺大，现在感觉很难有一下子提高，有时给几个点，或者收获几个知识点，已经非常难得。

小团队中微服务的可怕之处

保证在适当的时候选择合适的架构并且保持简单。关注代码架构和质量。

需求和架构设计

我们如何成功实现微服务迁移？

Picnic前一段时间进行了微服务迁移。迁移与技术团队的成长几乎同时发生，以前的单一技术团队被分成了专门的产品团队。

数据建模 & 企业级数据库设计原则

接手了严重过时的软件，到底是该逐步重构还是摧毁重写呢？

什么是“重写”和“重构”

可伸缩性最佳实践：来自 eBay 的经验

eBay杰出架构师Randy Shoup解释eBay在可伸缩性方面的各种关键实践，包括分区、水平伸缩、避免XA、异步性以及虚拟化等。eBay有数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节来计算。

可伸缩性原则

从最简单的水平来看，可伸缩性就是做更多的事情。这可以是响应更多的用户请求，执行更多的工作，或处理更多的数据。这篇文章针对构建可伸缩软件系统提出了一些原则和方针。

使用 DDT 思想重构项目：使用数据库保存数据，将数据驱动思想应用到项目

SOA 已死?

David Rubinstein最近在SD Times上发表了一篇煽动性的文章，文中他强调说，虽然SOA作为架构准则势头不错，但是技术本身或许已经消亡。文中他引用了分析师Jason Bloomberg的观点，后者认为SOA这个词用得不妥。Rubinstein认为SOA技术因为云计算以及Web服务固有复杂性而已然消亡。

这些公司为什么放弃微服务？

在微服务受追捧时，Uber、Botify、Segment等公司却放弃微服务，这是为什么？

微服务，够了

资深架构师Adam Drake在他的博客上分享了他对微服务的看法，他从自己的经验出发，结合Martin Fowler对微服务的见解，帮助想要采用微服务的公司重新审视微服务。以下内容已获得作者翻译授权，查看英文原文 Enough with the microservices。

如何设计一个分布式限流系统？

构建的可伸缩性和达到的性能：一个虚拟座谈会

加入到我们的业界重量级人物（eBay、Betfair、FiveRuns和Twitter）座谈会，他们探究了使网站尽可能可伸缩所需的成本，同时为获得尽可能好的性能所进行的调优。他们还探究了把应用做得尽量优秀的利和弊——他们始终处于其业务需求的压力之下。

过渡架构的作用：一周处理近百起高严重性事件，如何重写这个技术负债系统？

用“过渡架构”代替“重写”