大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
SOA实现中的4个最差实践
作者 胡键 发布于 2009年3月19日
在铺天盖地的SOA宣传文章中，最佳实践是出现频率最高的词汇之一。相比起来，最差实践就没那么风光了。但是，俗话说得好“吃一堑，长一智”，看看别人犯过的错，未尝对自己没有帮助。最近，Information Builders的市场副总裁Jake Freivald就撰文介绍了SOA实现中常见的4种最差实践，并针对每个实践给出了解决方案：
- 过分强调低级别的代码
- 上榜理由：重用性差，难以根据业务的变化迅速地做出反应。
- 解决办法：关注业务级别的服务。将整个系统切分成逻辑的构建单元——即所谓的服务——将创建出一个随业务需求一道成长的可持续解决方案。Jake Freivald将服务分为3层：细粒度服务、粗粒度服务和全局服务。并写道：
当组织过于强调细粒度的服务时，其结果就是有太多无法聚合成业务层服务的服务。照这种方式编码，将创建出难以维护或复用、低效且复杂的流程
- 集中设计和部署
- 上榜理由：其一，知识依赖个人，当这些人离开时，知识也随之一起离开；其二，个人不可能熟悉所有系统，当需要设计和构建服务的系统超出其知识范围时，难以设计出好的服务。
- 解决办法：分散服务创建。服务的分散化和本地维护，这使得粗粒度和全局服务的开发者不必时刻关心底层信息资产，而且底层服务开发者的变更不会影响到整个系统
- 撕碎并替换遗留软件
- 上榜理由：只看到了数据的重要性，却没有意识到遗留应用同样也是信息资产之一。并且由于对数据迁移的困难估计不足，造成项目延误，更有甚者直接有损于日常业务。
- 解决办法：重用为王。只要遗留系统还能工作，就不要管它。为技术而升级技术永远不是一个好的业务选择。
- 购买没有支持的软件
- 上榜理由：缺乏对操作SOA软件的足够认识，很可能会构建出过于复杂的系统，以及没有为任务选择合适的工具。
- 解决办法：要成功，就要有支持。就算企业有SOA架构师来帮助组织来建立SOA的原则，但要想成功，依旧需要把工作落到实处。
组织设计的成果是消息转换还是消息分拆，到底有多大影响？最好预先花时间把这搞明白，免得再在架构上线运行之后去去和效率问题相纠缠。通过足够支持的保驾护航，组织可以避免开发出过于复杂的系统，并知道哪个工具是针对哪项工作的合适工具。
Loraine Lawson对这篇文章评论道
Freivald特别提到了与“使用SOA作为一种集成解决方案”相关的最差实践。现在，我知道，有些人说SOA不应该用作集成。其总的观点是避免点对点、紧耦合的方式。但是，如果做得好，SOA可以解决很多你的集成问题。
Jignesh Shah则对于Freivald的“分散服务创建”表示出了不同看法（注：见该文的评论部分）。
看到服务的“集中设计和部署”被列为一个最差实践着实令人觉得有趣。我们越来越多地看到客户建立“共享服务”组织给他们乳臭未干的SOA来掌舵和提供动力。这样一个组织负责围绕企业范围内的核心系统识别、设计和交付服务。这有几个好处，包括可以全盘考虑整个企业的服务组合的塑形，简化资助模型，以及打通政策壁垒。
这样一个组织要对他们准备在其之上构建服务的系统非常了解，Freivald在这一点上是对的。这是为什么实际常常选择集成团队作为SOA共享服务组织的原因。这个小组有企业的视角，有处理核心系统的经验，理解异构环境下的挑战，并拥有所要求的中间件相关的技术技能。
Freivald建议的“分散服务创建”方法实际要求一个理想化的公司，在那里，他人利益排在每个小组利益的前面。这在大多数开始建立SOA的大型组织中实在难以出现。
Loraine Lawson在其文末还给出了一些确保SOA成功的文章的链接：
胡键 热心开源技术，《开源技术选型手册》作者，《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。
没有回复
关注此讨论 回复