【好书试读】架构即未来:现代企业可扩展的web架构、流程和组织

a41390bf1b29db5aabe301013108ebc1da5a25e3
这是一本教你如何建设一个世界级工程组织的实战手册,包括领导、架构、运维和过程。就像一本驾驶手册教你怎么起步、如何上路一样,本书告诉你如何扩展业务。有了这本书,就可以少犯错误。换句话说,如果你有什么疑问,那就去读这本书吧!
——郎·班德,Warby Parker技术副总裁

我在AKF公司一直负责解决棘手的技术难题。很多书阐述了如何纠正失效的产品架构或有问题的过程,这两点不言而喻都是问题的症状。本书不仅讨论这些症状,同时还剖析其根源,即弄清楚我们应该以何种方式管理、领导、组织和配置团队。
——杰瑞米·金,沃尔玛全球电子商务首席技术官兼高级副总裁

我喜欢这本书,因为它给我们上了重要的一课,教我们如何打造扩展性好的成功技术团队,进而提供扩展性好的技术解决方案,这是其他的技术书籍所不能企及的。本书有许多非常好的实战讲解,也包括如何建设扩展性文化、原则、过程和决策树的优秀案例。本书是我案头的常备书籍之一。
——克瑞斯·施里姆瑟,ZirMed首席技术官

本书内容之丰富出乎我的意料。扩展不仅是当大量用户同时使用时,如何避免网站崩溃的设计技术,而且教导如何管理公司在业务需求增长的时候不崩溃。作者一直奋斗在当今一些最成功的互联网公司的生产第一线,他们所分享的经验,不论好坏,其目的不仅仅是生存,更重要的是如何蓬勃发展。
——马提·卡根,硅谷产品集团创始人

对想要搭建大规模网上服务系统的人来说,这是一本必读的书。
——戴拿·斯塔德,Matrix公司合伙人

对于系统的扩展性,不论是大型企业还是小型企业,马丁和迈克尔都是经验丰富的人。在处理扩展性方面,他们的独到之处在于先聚焦于真正的基础,即人和过程,否则就无法获得真正的扩展性。对于扩展性,马丁和迈克尔以一种简单易行的方式来发挥经过他们多年验证的成功经验。
——杰佛瑞·韦伯,Shutterfly互联网运维/IT副总裁

如果想要得到最好的健康诊断结果,我会选择去Mayo诊所。如果想要了解我们所投资企业的系统性能和扩展性,我会给马丁和迈克尔打电话。他们针对性能和扩展性所给出的推荐方案,使我属下的几个公司避免了系统的彻底重构。
——华伦·魏茨,Foundation Capital合伙人

在PayPal和eBay的时候,我在迈克尔和马丁的手下担任经理,有机会直接学习和借鉴他们在这本书中提到的经验与教训,这对我目前在Facebook的工作有无限的价值。
——黄易山,Reddit公司前CEO,Facebook工程部门前总监

本书是迄今为止介绍扩展性方面最好的一本书。作者从过程、人员、性能和技术的角度解决扩展性问题。不论你的组织机构是刚刚开始,边干边定义过程,还是处在一个成熟的阶段,无论是事前、事中或事后,本书都是能够帮助你解决扩展性问题的理想指南。在经历了几个公司和项目,并把系统从小做大后,我可以负责地说,真希望能在一年、五年和十年前就读过本书。
——杰瑞米·莱特,b5media公司首席执行官

迈克尔和马丁亲眼目睹了eBay、PayPal和其他几家公司快速扩展所带来的挑战,世界上具有这种经验的人为数不多,成功战胜这种挑战的人就更少了。本书把作者从世界上最大的两个互联网公司在系统扩展方面所积累的经验教训做了极好的总结和概述,对于任何一个处于高速增长公司的执行人员来说,这都是一本非读不可的书。除此以外,本书文笔流畅,幽默风趣,使我爱不释手。
——凯文·福图纳,AKF公司合伙人

以互联网为核心的信息技术正在快速地扩大商业的边界。从前,大多数的软件和信息管理系统仅仅服务公司内部的几百名员工,但今天很多软件系统已经演变成要服务亿万客户的商业平台,甚至如马云先生所言,软件系统已成为社会经济生活新的基础设施。在这个过程中,软件系统的可扩展性将成为这个公司是否可以升级涅槃至关重要的问题。本书译者敏感地关注到这个问题,把这本好书译成中文,相信可以激发中国新经济的管理者、从业者的思考和讨论。
——涂子沛,阿里巴巴副总裁,“互联网+”专家,《大数据》《数据之巅》作者


架构未来》这本书的第12章简单阐述了架构设计的一些常用的原则(后面章节会详细阐述)。这些原则中很多都是在架构一开始的设计中就要考虑进去的,这样在出现任何问题时,我们都能够及时的处理,和把问题影响的范围有效的缩小。否则就像我现在的项目,一开始设计时,考虑的很少,出问题时,没有做到及时的反馈,和缩小影响范围,只能在事故的代价中将所需要的原则添加进来,慢慢完善。 1.N+1设计 要确保任何你所开发的系统在发生故障时,至少有一个冗余的实例。 一个实例确实很危险,当这个实例出现不明原因的问题不能对外服务,需要debug的时候,如果优先debug,那当前实例就要暂停服务直到你找到问题为止。如果你直接重启实例恢复服务,就没有事故现场进行debug了。而这时如果有一个冗余的实例,就可以先让冗余的实例对外服务,事故现场的环境也得以保留。 多个实例来做负载均衡也是一种不错的选择。 2.回滚设计 确保系统可以回滚到以前发布过的任何版本。 以前做游戏的时候经常遇到回滚,有时候是数据库回滚,有时候是服务器端回滚,一般都是回滚到上个版本。 3.禁用设计 能够关闭任何发布的功能。 当一个功能出现严重问题不得不关闭时,如果关闭整个系统代价就有点大了,所有要有单个功能的开关。像商城系统的支付功能就一定要有开关,如果出现比较严重的bug,可以关闭支付而不影响下单。 4.监控设计 在设计阶段就必须要考虑监控,而不是在实施完成之后补充。 如果监控做的好,不仅能发现服务的死活,检查日志文件,还能收集系统相关的数据,评估终端用户的响应时间。如果系统和应用在设计和构建时就考虑好监控,那么即使不能自我修复,也至少可以自我诊断。 5.设计多活数据中心 不要被一个数据中心的解决方案把自己限制住。 有钱就多建一个,让股东放心。 6.只用成熟的技术 只用确实好用的技术。 不管用什么技术,都要确保是一个成熟的技术。也许某个新技术有众多优点,比如,降低开发成本,提高开发效率,提高可扩展能力,减少终端用户的响应时间。但是,只要这项技术故障率比较高,就绝不能使用。 7.异步设计 只有在绝对必要的时候才进行同步调用。 异步适合并发。 8.无状态系统 只有当业务确实需要的时候,才使用状态。 无状态的系统更利于扩展,更利于做负载均衡。 9.水平扩展非垂直升级 永远不要依赖更大、更快的系统。 微服务是水平扩展的一个例子,不要把所有的功能都集中在一个系统里面。必要的时候把需求分为多个系统,而不是升级原有的系统。 10.设计至少有两个步骤的前瞻性 在扩展性问题发生前考虑好下一步的行动计划。 想的更远一点,就能减少重构的次数。 11.非核心则购买 如果不是你最擅长的,也提供不了差异化的竞争优势则直接购买。 云服务这种的就购买好了。 12.使用商品化硬件 在大多数情况下,便宜的是最好的。 硬件这块儿,满足需求即可,在必要的时候增加配置。 13.小构建,小发布,快试错 全部研发要小构建,不断迭代,让系统不断地成长。 小版本的失败率较低,因为失败率与解决方案中的变更数量直接相关。 14.隔离故障 实现隔离故障设计,通过断路保护避免故障传播和交叉影响。 避免多系统之间的互相影响,这个很重要。 15.自动化 设计和构建自动化的过程。如果机器可以做,就不要依赖于人。 人常犯错误,更令人沮丧的是,他们往往会以不同的方式多次犯同样的错误。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值