大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
JOSH：企业软件组合的新提议
作者 Abel Avram 译者 郭晓刚 发布于 2009年4月4日
Grey Lens Man，这位戴灰墨镜的神秘人发了一篇很有意思的博客文章，谈正折磨着许多企业的遗留问题，并提出了一种新的软件组合作为解决之道——JOSH，也就是JSON、OSGi、Scala和HTTP。
灰镜人先说了一个似曾相识的企业IT故事：
跟你说，我有个小问题——3百万行RPG和COBOL，5,500个逻辑和物理文件分散在几台不是很便宜的AS400上。过了这么些年，情况更妙了——系统经过克隆和分支，现在有好几个不兼容的版本分布在全世界。
实际维护起来不是一般的痛苦：
折磨人的细节我就不说了，我就说个例子吧。在这2.5T数据当中，客户文件里面有个特殊的标志，决定了客户与系统的交互方式将会有根本区别，而它的位置是Filler3左数第三个字节（译注：COBOL习惯用Filler补足记录长度或者分隔字段，本不应存放有意义的数据）。还有一个文件，它的“账户ID”列有时候真的保存了账户号码，有时候又不是，真难为死我们了。你再猜猜“邮编”列存的是什么？（提示：一点都不像邮政编码）。
谈到问题的解决之道，灰镜人很坦白：
没人想让它[遗留系统]苟延残喘下去，所以再牺牲人力去与熵作对，或者给这头猪涂点SOA的口红，都不是我们想要的。问题是根本性的、系统性的。
灰镜人提出的方案是JOSH，也就是JSON OSGi Scala HTTP：
JSON完成了XML许下的承诺。简单易懂，人类和机器都能轻松使用的高效数据表示。序列化/反序列化速度持平或超过XML、Thrift和Protocol Buffers。没错，我会损失XSD Schema类型检查、SOAP和WS-*的标准化。可我看划得来。
OSGi是标准化的组件和服务动态模块框架。挑一个日志组件、一个HTTP服务器组件、一个别的什么组件，加上你自己的组件做集成，一个专用的应用方案就拼好了。精简的部署方案加上真正的可替换能力。我失去的是什么呢？加载了25个框架的巨型J2EE应用，SCA和XML的配置深渊。成交。
HTTP简单，高效，足够快，又受到广泛的支持。为了把简单的数据从A移到B，搞出一个又一个复杂的专有协议，还因此要和防火墙端口一类的麻烦纠缠不清，我受够了。是的，HTTP不够完美。但只要有可能，我乐意。
所有接口都将是基于HTTP+JSON的简单API，向REST靠拢。这就是JOSH组合立竿见影的效果。
Scala是JOSH组合中最艰难又最容易决定的选项。我反复思量，远比JSON或XML或Thrift或Protocol Buffers的抉择困难得多。
Ted Neward欣赏灰镜人的方案，但也指出了一些顾虑：
表面上看，这个组合非常漂亮。管理Java系统的版本和模块，OSGi是很可靠的规范。更重要的是它为人们所熟悉、不容易出问题、处理典型问题方面又久经考验。……
但有几点需要审慎考虑。JSON是一种简单的传送协议，没错，但这件事有好坏两个方面（比如它是以对象为中心的，因此在处理某些关系的时候会遇到跟对象一样的问题）。而且它不像XML那样无处不在。是的，XML有滥用的问题，但当为了和各种不同系统通信而寻找一个共同基础的时候，普遍性是不得不考虑的问题。……
HTTP很适合远距离的、客户端发起的通信，但它绝对存在局限（灰镜人也坦率承认，值得赞扬），至少对于面向内部的应用存在缺点。
JOSH组合还缺了很重要的一层，持久化层的方案灰镜人尚在寻找当中。Ray Krueger提了一个JOSCH的建议，其中的“C”代表CouchDB。灰镜人赞成这个方向，但他更推崇Cassandra或者Voldemort。Neward也赞成CouchDB是可以考虑的方案，还提出db4o也值得考虑。他甚至给.NET也想了一套对应的组合：JSON + Assemblies + F# + HTTP = JAFH。
查看英文原文：JOSH: A Proposed Software Stack for the Enterprise
译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。
没有回复
关注此讨论 回复