分布式技术一周技术动态 2016-10-30

Posted 2020-08-16

 

分布式系统实践

1. 微信PaxosStore内存云揭秘：十亿Paxos/分钟的挑战

http://dwz.cn/4r4gDD

摘要: PaxosStore是微信设计的一套分布式存储系统，并已对核心业务存储做了架构改造。内存云是微信PaxosStore存储体系的组成部分，本文将分享内存云的Paxos改造过程。这还是我第一次看到大规模的运用基于Paxos的强一致性分布式存储系统的应用案例, 而且运用在微信这样的重量级产品上, 值得学习.

2. 以两军问题为背景来演绎BasicPaxos

http://dwz.cn/4sAyew

摘要: 这篇文章挺有意思, 以两军问题为背景, 类似讲故事的方法, 非常清晰的阐述了BasicPaxos协议的全过程, 既生动形象, 又深入浅出, 推荐给大家.

服务化和虚拟化

1. 每秒上百万次的跨数据中心写操作？Uber是如何使用Mesos和Cassandra来处理的

http://dwz.cn/4r4nEN

摘要: 这篇文章介绍了Uber是如何使用mesos部署大规模Cassandra集群的, 我们都支持容器技术或者微服务技术对于无状态的服务具备非常好的技术支持, 但是针对有状态的服务却要复杂的多, 需要考虑数据的迁移以及多维度的资源隔离等因素, 虽然这篇文章没有透露太多的技术细节, 但是至少说明技术上是可行的, 也为我们推动存储类服务和计算类服务的全混布增强了信心.

2. 微服务技术栈选型，看了这个别的可以不用看了

http://dwz.cn/4s49Jb

摘要: 现阶段微服务概念可以说是深入人心, 很多技术会议上只要议题有"微服务"字样, 那都是场场爆满. 随之而来的是开源社区中涉及微服务的开源技术也是五花八门, 目不暇接. 这篇文章非常全面的总结了现阶段开源社区的整个微服务技术栈, 开完这篇文章之后可以对整个微服务技术栈有一个非常全面的了解. 不过受限于时间关系, 仅仅是技术的罗列, 没有深入, 有兴趣的同学可以自行深入研究, 相信会收货满满.

 高可用技术

1. 老司机的微服务架构实现，照亮你的人生

http://dwz.cn/4qKxad

摘要: 微服务系统本质上是一个分布式系统，而分布式系统就有其固有的复杂性，对测试，部署甚至团队的组织结构都会带来很大挑战。本文介绍了德比软件的微服务架构实现, 有了这些微服务架构的基础设施，能有效帮我们解决并规避一些问题，但我们仍然不能低估采用微服务架构带来的复杂性。微服务架构不是银弹，更不是免费的午餐，实施微服务改造是要付出代价的，根据业务的需求选择合适的架构，不要为了微服务而微服务。

2. 服务的交互，构建微服务架构的最佳实践

http://dwz.cn/4sD6dD

摘要: 微服务架构提倡有许多职责单一的小服务组成，这些服务之间互相交互。然而这就造成了一系列的问题，比如：服务之间如何发现彼此？是否采用统一的协议？如果一个服务无法与其他服务通信会怎样？这篇文章讨论部分相关话题。

运维和DevOps 

1. 一个足以让私有云服务彻底崩溃的“小坑”-聊聊CMDB的资产审计

http://dwz.cn/4s3M14

摘要: CMDB管理公司的全部设备资产, 所以CMDB的准确性非常重要. 我们在和INF合作开展机器管理项目过程也踩了不少类似的坑, 比如故障探测agent挂掉导致信息不准确, 各种系统bug或者认为问题导致流程卡单, 状态变更无法追溯等等, 这篇文章介绍了汽车之家CMDB中利用变更日志来对资产设计了“盘”、“审”、“罚”为核心的自我审计方案, 值得参考.

2. 深度剖析开源分布式监控CAT

http://dwz.cn/4tfIIN

摘要: CAT是美团自主研发并且开源的分布式应用性能分析系统, 用于监控服务的行为, 开源以后被应用于很多知名的企业,  比如携程、陆金所、猎聘网等. 这篇文章详细介绍了CAT的核心原理, 对于想要构建APM(Application Performance Monitor)的同学来说非常有参考价值, 不过目前CAT只支持Java语言.

 

基础和文化

1. 从Google的单代码库模式看Google工程文化

http://dwz.cn/4rip8T

摘要: google的单根代码树可能很多同学都不陌生了, 这篇文章在介绍google单根代码树的同时, 也对google的工程师文化进行了解读, 真的是非常佩服google那些奠基这些基础设施的先贤们, 因为一旦养成了习惯, 就很难改变了.

2. 取舍与敏捷–来自张小龙的分享

http://dwz.cn/4thmg2

摘要: 这是张小龙微信群组一年一度的领导力大会上的发言, 张小龙强调了做产品的初衷是最大限度的满足用户体验而不是一味的追求一些所谓的数字指标, 数字有时候是会骗人的, 一味的追求数字会让我们的创造力首先限制. 同时张小龙还强调了敏捷, 当一个产品非常庞大的时候, 人员非常多的时候, 大家对于产品的变更可能自然而然的就会放慢脚步, 觉得他应该就是这样的变化速度. 其实这是非常危险的, 这会让团队变得低效, 阻碍新的想法的产生. 试想任何一个突如其来的灵感, 如有都要3个月才能上线, 那么很多情况下, 激情就会被磨灭. 所以张小龙以腾讯邮箱的例子来呼唤敏捷. 这也是我们高可用架构团队, 尝试DevOps的根本出发点.