观其设计知其人
A MAN is KNOWN by the DESIGN he keeps
原文:Most Useful Software Architecture Patterns by Shadman Jamil
最常用的架构模式
分布式ID生成方案
不管我们是不是有身份的人，我们一定是有身份证的人，身份证上面的号码就是我们的ID，理论上这个ID是全国唯一的，而且通过这个号码，我们还可以得到一些个人信息，比如前两位可以确定我们第一次申请身份证的时候所在的省份、接下来的四位可以确定我们所在的区县，然后还可以知道我们出生的年月以及性别。
在我们的计算机应用中，也处处存在的ID， 比如订单编号、商品ID、微博ID、微信消息ID、书的ISDN号、商品条码等等。通过ID，可以迅速定位到对象实体、为对象之间建立关联、跟踪对象在不同服务之间的流转等等。
有的ID是无意义的唯一的标识，有的ID还能提供额外的信息，比如时间和机房信息等等。为了确保唯一性，有的ID使用很长的字节数，比如256个字节，有的通过递增的long类型，只需要8个字节来表示。考虑到存储、信息包含量、性能、安全等因素，一个好的ID的设计至关重要。
介绍ID生成和分布式的方案的文章已经非常非常多了，比如文末中的参考资料中的文章，所以我在本文中简洁的汇总各个方案的优缺点，然后介绍一个分布式的ID生成器项目rpcxio/did,它可以实现单节点百万级的ID生成。
流行的rpc框架benchmark 2018新春版
随着公司规模的扩大，以及业务量的激增，单体应用逐步演化为服务/微服务的架构模式， 服务之间的调用大多采用rpc的方式调用，或者消息队列的方式进行解耦。几乎每个大厂都会创建自己的rpc框架，或者基于知名的rpc框架进行改造。
目前, rpc框架主要沿着两条路线发展，一个是目标为了跨语言，服务端可以用不同的语言实现，客户端也可以用不同的语言实现，不同的语言实现的客户端和服务器端可以互相调用。很显然，要支持不同的语言，需要基于那种语言实现相同协议的框架，并且协议设计应该也是跨语言的，其中比较典型的是 grpc,基于同一个IDL，可以生成不同语言的代码，并且语言的支持也非常的多。
另一个rpc框架发展的目标是支持服务治理，主要的精力放在服务发现、路由、容错处理等方面，主要围绕一个语言开发，可能也有一些第三方曲折的实现服务的调用和服务的实现，这其中的代表，也是比较早的开源的框架就是阿里巴巴的dubbo。
有些rpc框架协议的涉及一开始就没有考虑的跨语言，其中使用了语言的一些特有的属性，比如Java的ObjectInputStream/ObjectOutputStream, Golang的Gob等，有些在协议的设计上就考虑了通用性， 使用JSON或者Protobuffer作为数据序列化。
有些框架是基于TCP的二进制流的数据传输，有些基于http的request/response模型进行请求，也有基于http2的流式传输，更有一些支持可信赖的UDP进行数据传入，比如quic、kcp等。
有些提供了生态圈的一些框架，比如gateway、agent等，有些restful风格的rpc框架天然支持API gateway进行负载均衡。
有些已经得到了大厂的广泛应用，有的大厂内部得到了大量应用，但目前还没有广泛的推开来。
选择一个rpc框架会基于多方面的考虑： 框架特性、性能、成熟度、技术支持、社区活跃度等多个方面，本文只比较各个流行框架的benchmark，基于几个固定的场景提供benchmark数据支持。
Kafka的复制机制
最近在设计一个多分区多副本的消息系统，以前对kafka有一些了解，在阅读了阿里的RocketMQ、小米的Pegasus等分布式系统后，再仔细阅读的kafka的复制设计，整理出本篇文档，可以和其它系统做一个对比。
Kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：
- 通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
- 高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
- 支持通过Kafka服务器和消费机集群来分区消息。
- 支持流式处理。
7年过去了， kafka已经成为一个羽翼丰满的发布订阅平台、消息存储、流处理的工具。财富500强企业中有三分之一的公司使用了kafka平台。也就是在昨天(2017年11月1日)，kafka发布了它的1.0.0版本。
本文主要参考了Jun Rao(饶军)的Intra-cluster Replication in Apache Kafka, Jun Rao毕业于清华大学，哥读到博士，后来在IBM、LinkedIn工作，在LinkedIn期间任Kafka组的技术leader。2014年Kafka一帮人成立了Confluent公司，推广Kafka的商业应用，Jun Rao是共同创始人。
[转]设计一个容错的微服务架构
原文: Designing a Microservices Architecture for Failure
翻译: 设计一个容错的微服务架构 by Jason Geng
微服务架构使得可以通过明确定义的服务边界来隔离故障。但是像在每个分布式系统中一样，发生网络、硬件、应用级别的错误都是很常见的。由于服务依赖关系，任何组件可能暂时无法提供服务。为了尽量减少部分中断的影响，我们需要构建容错服务，来优雅地处理这些中断的响应结果。
本文介绍了基于RisingStack 的 Node.js 咨询和开发经验构建和操作高可用性微服务系统的最常见技术和架构模式。
如果你不熟悉本文中的模式，那并不一定意味着你做错了。建立可靠的系统总是会带来额外的成本。
2016年Web框架性能基准
TechEmpower最近发布了他们的第13轮的web框架的性能测试，得到了一些有价值的测试结果。
由于年初前一轮的测试遭遇到了硬件的瓶颈，微软 Azure 和 ServerCentral 分别提供了云主机和物理主机环境，所以第13轮的测试是在新的测试环境中进行的，所以你把这轮的测试结果和以前的测试进行比较的话可能不太合适。
- ServerCentral
- 物理机环境,由 ServerCentral提供。 Dell R910 (4x 10-Core E7-4850 CPUs) 为应用服务器; Dell R420 (2x 4-Core E5-2406 CPUs) 为数据库服务器; 10G网络
- Azure
- 云测试主机由 Microsoft Azure D3v2 实例提供; 10网络
产品级微服务的八大原则
虽然微服务架构给开发者带来很大的自由，但是确保服务的可用性却要求对微服务进行很好的架构，运维以及组织标准。
O'Reilly这本免费的电子书Microservices in Production介绍了微服务标准化的挑战，以可用性作为微服务标准化的目标，提出了八个标准化微服务的原则，包括在整个工程组织中实现production-readiness标准的策略。
这本书的作者是 Susan J. Fowler, Uber 的 SRE (site reliability engineer)，她在Uber也主要做促使Uber项目中的各个微服务达到产品级的状态，所以这本小书也是她的工作思考之作。
