淘宝平台架构师谈海量互联网服务技术架构.pdf资源-CSDN文库

版权申诉

32 浏览量 2021-10-25 15:03:02 上传评论收藏 142KB PDF 举报

资源推荐

资源详情

资源评论

林昊，网名 BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人

的研究方向主要为 Java 模块化、动态化系统的构建以及高性能的大型分布式 Java 系统的构

建。曾编写《OSGi 实战》和《OSGi 进阶》两篇 Opendoc，为 OSGi 在中国的推广起到了很

大的作用。

王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容

灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑

哪些情况？

林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性

能状况（例如一次查询必须在 3ms 内完成）来决定。当达到性能瓶颈时，通常需要进行数

据的拆分或备份等策略，在这个过程中最需要考虑的，就是对应用的影响程度，因此通常会

需要一个强大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，

另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构并

存、数据冗余和同步等问题。

王速瑜：数据备份问题：对于大容量的数据备份，技术上如何做到不影响正常的服务？

如何合理制定冷备、热备的实施策略、方式、时间段？在数据损坏、主服务器硬件损坏等故

障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？

林昊：对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知

实现数据备份，或基于高端数据库的特性（例如 Oracle 的 Standby）。对于冷备、热备的实

施，原则要求均为不影响正常业务功能，因此可选的时段只能是系统访问量较低的时段。方

式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率

的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切换，就必须依赖强

大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机

制，自动切换备库为主库，并通知所有应用转换为连接和使用新的主库，如果做不到自动

的话，这个过程就仍然得基于“人肉”来进行操作了。

王速瑜：开放平台设计问题：开放平台 API 设计中，调用协议设计时有哪些考虑要求？

对于请求类的调用协议设计，倾向于 call?A=a&B=b 这种方式（这种方式对调用者比较方便，

但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比如 WSDL、

XML 等？对用户鉴权的 Token 机制是怎样的？有没有对接入方进行 QoS 的考虑，是怎么做

的?

林昊：对于开放平台而言，基本上目前 Facebook 引领了开放平台的技术，因此在协议

上多数都采用 Http，接口的设计上则都倾向于 REST 风格；对于用户鉴权的 Token 机制上通

常都是采用一个公私钥的匹配方式，并且此 Token 一定是由开放平台公司所提供；开放平

台中是肯定会对接入方的 QoS 有限制的，并且这通常也影响到了开放平台的收费标准，在

实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电信行业。:

王速瑜：跨 IDC 部署程序模块在业务发展到一定阶段后在所难免，跨 IDC 的专线资源相

对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断

的容灾措施？

林昊：跨 IDC 部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其

次是部署所耗费的带宽成本和时间成本，对于部署结果验证而言，通常可采用的方法为业

务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而

言，通常需要借助自动化的部署系统。

王速瑜：Web2.0 网站的海量小文件的存储，如用户头像、相册微缩图等文件，这些文

件的特点是尺寸小（100KB 以内），数量巨大（数以百万计），这些文件的存储、读取、备份

都是问题，请问您是如何提供具体解决方案的？

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余1页未读，立即下载

内容反馈

版权申诉

苦茶子12138

粉丝: 1w+
资源: 6万+

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip