分布式追踪系统架构与设计.docxVIP

PAGE 1 PAGE 1 分布式追踪系统架构与设计  Guice  大多数人不熟识Guice，这是一个谷歌开发的依靠关系管理框架。TDist集成到我们现有的服务模块，那么我们的客户端将更简洁、更少出错，我们依靠的就是Guice，并且实现了多个模块可以让我们的客户端更易于安装。Guice处理依靠于在对象实例化期间注入，在交换接口也能更简洁。假如通过这篇文章你已经开始思索集成TDist，那么听起来很复杂。许多时候，我们的客户端需要安装附加的Guice模块，这些模块将绑定到我们的追踪实现上，实现现有的Thrift接口。这也意味着，我们的客户端不能实例化任何我们追踪启动的构造。无论什么时候，一个TDist客户端忽视绑定一些东西，Guice都会在编译时通知我们的客户端。我们把许多心思放在如何制定我们的Guice模块层次结构上，因此TDist不会与我们的客户端冲突，我们都很小心，无论什么时候，我们都必需暴露元素到外部世界。  追踪消息总线  全部我们的客户服务在使用之前都会放置追踪数据，追踪消息总线是通过Zipkin收集器来持续收集的。我们的两个选项是Kafka和Kinesis，不过最终我们选择了Kinesis。我们考虑到Kafka是因为Knewton已经稳定部署Kafka许多年。在那时，我们的Kafka集群一直使用我们的子事件总线，在生产环境中每秒产生超过300条消息。我们初步估计将超过400，000条的跟踪信息，每秒只有部分进行集成。生产系统与仪表数据使我们紧急。Kinesis好像是一个有吸引力的替代，它将我们从Kafka服务器分别，这只是生产数据，而不是仪表上的数据。在实现的时候，Kinesis是一个新的AWS服务，我们对它很熟识。它的价格，吞吐能力，不用太多维护，这些促成了我们达成全都。总的来说，我们已经满足它的性能和稳定性。它没有Kafka那么快，但是Kafka数据产生的性质，它从产生到摄入SLA甚至要几分钟。自从我们部署追踪消息总线到生产环境，我们也很能简单扩展大量Kinesis，且不会引起任何宕机。  追踪数据的存储  全部我们追踪的数据都会被放在追踪数据存储。数据放在那里是有一个配置时间的，并且由Zipkin查询服务显示在UI上。Zipkin供应了大量开箱即用的数据存储，包括Cassandra，Redis，MongoDB，Postgres和MySQL。我们对Cassandra和DynamoDB做过试验，这主要是因为我们在Knewton中获得的习以为常的学问，最终我们还是选择了亚马逊的ElasticacheRedis。下面这些是我们做出这个打算的最重要原因。 花在生产上的时间，我们还没铺开就要交付了，并且，我们还要维护一个新的集群 成本  与Zipkin集成更简洁，代码更少  在数据上支持TTLs  结论  现在在Knewton，我们的追踪解决方案在整个环境中已经运行好多个月了。目前它已经被证明是特别有价值的。我们只有在开始擦除那个面的时候，我们才可以追踪并且收集时间数据。我们有许多好玩的实现，并且在Knewton交付，之后，我们就理解了这个数据的价值。