林昊，网名BlueDavy，China OSGi User Group Director，淘宝网
平台
架构部架构师，个人的研究方向主要为 Java模块化、动态化
系统
的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi 在
中国
的推广起到了很大的作用。
1 U: @% ~8 @* M2 \7 @4 L7 G
王速瑜： 数据 集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？
林昊： 一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在 3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对 应用 的影响程度，因此通常会需要一个强 大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构 并存、数据冗余和同步等问题。
王速瑜： 数据备份问题：对于大容量的数据备份， 技术 上如何做到不影响正常的 服务 ？如何合理制定冷备、热备的实施策略、方式、 时间 段？在数据损坏、主 服务器 硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？
林昊： 对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据 库的特性（例如 Oracle 的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务 功能 ，因此可选的时段只能是系统访问量较低的时段。方 式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切 换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接 和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。
王速瑜： 开放平台设计问题：开放平台 API 设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计， 倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比 如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的?
林昊： 对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http， 接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供； 开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电 信行业。 0 p9 ~ T! _/ l7 E/ `$ p: m( a
王速瑜： 跨 IDC 部署 程序 模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？ & d) L) s1 W9 v! |
林昊： 跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和 时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要 借助自动化的部署系统。
王速瑜： Web2.0网站的海量小 文件 的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体 解决 方案 的？
林昊： 目前 互联网 公司，例如Google、优酷等，对于小文件或大文件的存储都有自己的一套解决方案，而并不会 去依赖高端的存储设备来解决。一方面是成本问题，另外一方面是伸缩问题，因此对于这些文件的存储、读取和备份多数都采用了类似GFS的方案或直接采用 Hadoop提供的HDFS方案。
王速瑜： 互联网产品部署是一个很关键的环节，很多互联网公司依然采取手工部署发布产品版本的方式，但是这种方式 比较复杂而且低效，往往很容易出错，如果同时发布几个产品时，如果产品之间关联比较紧密，其中一个发布出错就会影响到其他的发布，请问作为架构师，您在日 常工作中是如何解决这样的问题？您的团队中是否考虑自动化动态部署，具体方案是怎么样的？
林昊： 在部署这个问题上，目前好像只有国外的几家互联网公司做的不错，其中最典型的是eBay。eBay在很多 年前就已经做了一套自动化部署系统，在这套系统中，eBay可以将一次发布中的几个产品进行依赖关系的分析，从而决定其发布顺序，并可实现自动的发布、校 验和回滚，这套系统相信也是现在中国几家互联网公司都在追求的目标。
王速瑜： 作为互联网技术架构师，您能简单总结一下海里互联网服务技术架构方面的理念、原则，方法吗？
林昊： 我觉得eBay的五点总结基本已经够全面：
（1）“ 拆分”， 数据库 的拆分以及应用的拆分，当然这需要强大的技术的支撑，这点要做到的目标通常是便于应用的无限水平伸缩； 7 u( r( S, K k; [
（2）能异步就异步，这需要业务的允许； / M! \; h) G0 G8 U& T* k3 Q
（3）能自动就自动，就像自动化的部署系统； 8 L0 X# q: d* T/ v
（4）记住所有失败的事情，这点非常重要；
（5）容忍不一致性，这句话的含义是尽量少用强事务，而是采用最终一致性这类方案。 3 x1 R. ^# z( C: {, C
当然，除了上面这五点之外，还有像多用缓存、自行实现关键技术（以控制稳定性、性能和做到及时响应）等。 1 d. ~" x. ?4 g2 ~# t+ c9 |
王速瑜： 有很多优秀的 软件 架构师能力很强，但是由于缺乏海量服务技术应用和实践的机会，不能很好地进行海量服务应用的架构设计，您能给他们一些宝贵建议，分享一下您是如何不断 学习 成长起来的？您有哪些提高技术视野的方法和途径，比如有哪些书籍可以推荐，哪些优秀的网站可以推荐？ , o) H9 ^! S/ g1 G9 _8 y
王速瑜： 数据 集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？
林昊： 一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在 3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对 应用 的影响程度，因此通常会需要一个强 大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构 并存、数据冗余和同步等问题。
王速瑜： 数据备份问题：对于大容量的数据备份， 技术 上如何做到不影响正常的 服务 ？如何合理制定冷备、热备的实施策略、方式、 时间 段？在数据损坏、主 服务器 硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？
林昊： 对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据 库的特性（例如 Oracle 的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务 功能 ，因此可选的时段只能是系统访问量较低的时段。方 式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切 换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接 和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。
王速瑜： 开放平台设计问题：开放平台 API 设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计， 倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比 如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的?
林昊： 对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http， 接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供； 开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电 信行业。 0 p9 ~ T! _/ l7 E/ `$ p: m( a
王速瑜： 跨 IDC 部署 程序 模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？ & d) L) s1 W9 v! |
林昊： 跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和 时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要 借助自动化的部署系统。
王速瑜： Web2.0网站的海量小 文件 的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体 解决 方案 的？
林昊： 目前 互联网 公司，例如Google、优酷等，对于小文件或大文件的存储都有自己的一套解决方案，而并不会 去依赖高端的存储设备来解决。一方面是成本问题，另外一方面是伸缩问题，因此对于这些文件的存储、读取和备份多数都采用了类似GFS的方案或直接采用 Hadoop提供的HDFS方案。
王速瑜： 互联网产品部署是一个很关键的环节，很多互联网公司依然采取手工部署发布产品版本的方式，但是这种方式 比较复杂而且低效，往往很容易出错，如果同时发布几个产品时，如果产品之间关联比较紧密，其中一个发布出错就会影响到其他的发布，请问作为架构师，您在日 常工作中是如何解决这样的问题？您的团队中是否考虑自动化动态部署，具体方案是怎么样的？
林昊： 在部署这个问题上，目前好像只有国外的几家互联网公司做的不错，其中最典型的是eBay。eBay在很多 年前就已经做了一套自动化部署系统，在这套系统中，eBay可以将一次发布中的几个产品进行依赖关系的分析，从而决定其发布顺序，并可实现自动的发布、校 验和回滚，这套系统相信也是现在中国几家互联网公司都在追求的目标。
王速瑜： 作为互联网技术架构师，您能简单总结一下海里互联网服务技术架构方面的理念、原则，方法吗？
林昊： 我觉得eBay的五点总结基本已经够全面：
（1）“ 拆分”， 数据库 的拆分以及应用的拆分，当然这需要强大的技术的支撑，这点要做到的目标通常是便于应用的无限水平伸缩； 7 u( r( S, K k; [
（2）能异步就异步，这需要业务的允许； / M! \; h) G0 G8 U& T* k3 Q
（3）能自动就自动，就像自动化的部署系统； 8 L0 X# q: d* T/ v
（4）记住所有失败的事情，这点非常重要；
（5）容忍不一致性，这句话的含义是尽量少用强事务，而是采用最终一致性这类方案。 3 x1 R. ^# z( C: {, C
当然，除了上面这五点之外，还有像多用缓存、自行实现关键技术（以控制稳定性、性能和做到及时响应）等。 1 d. ~" x. ?4 g2 ~# t+ c9 |
王速瑜： 有很多优秀的 软件 架构师能力很强，但是由于缺乏海量服务技术应用和实践的机会，不能很好地进行海量服务应用的架构设计，您能给他们一些宝贵建议，分享一下您是如何不断 学习 成长起来的？您有哪些提高技术视野的方法和途径，比如有哪些书籍可以推荐，哪些优秀的网站可以推荐？ , o) H9 ^! S/ g1 G9 _8 y
林昊：这个问题提到点子上了，很多架构师不知道如何应对大型、高并发的场景，最主要的原因是没有这样的实践的机 会，毕竟目前只有在大型企业系统或互联网才能获得这类难得的实践机会，通常在没有实践机会的情况下是很难完全理解这些技术的。多数情况下，互联网中的技术 方案都是在多次血泪宕机下成长起来的，建议只能是多看各种互联网技术介绍的文章，例如Google共享了很多，还有网上也有很多各家互联网公司技术架构文 章的介绍，尤其是那类技术发展历程的介绍，可以设想下如果自己碰到这样的问题，会如何去解决，也许这样能慢慢掌握和理解大型、高并发系统的解决方案。书籍 方面目前国内各种高性能方面的书也开始不断冒出了，例如有《MySQL性能调优与架构设计》、《构建高性能的Web站点》、《构建Oracle高可用环 境》等，这些高性能的书通常都来源于作者亲身的经验，是非常值得学习的；另外要知道：如果想做到高性能，通常意味着要对软件（包括OS等）以及硬件技术都 有充分的掌握，因此像《深入理解JDK》、《深入理解Linux内核》、《深入理解计算机系统》这些书也是非常值得一看的。至于网站方面，像http://highscalability.com/、http://www.javaperformancetuning.com/这些都是非常不错的网站。
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
