《执行SOA》上市了

执行SOA--SOA实践指南

译者序

几年前，为了尝试JDK 1.5中的并发包，我写了一个多线程的网页爬虫程序，利用线程池来抓取和分析页面。

并发200个线程，每个线程从待爬URL队列中取得一个URL，取回网页，进行分析，找出其中的URL链接，再放入待爬队列。开发过程很正常，但在测试中遇到了问题。在爬了7万多个网页之后，程序开始越来越慢。凭感觉判断，有一些线程“死”掉了。

多线程的调试并不是件容易的事。这个问题很“难”再现。这不是普通意义上的难再现，它每次都会出现。但要跑到7万多URL时，才会出现。也就是说，再现这个问题的代价很大。我试过将线程池的大小退化到 1，想找出什么样的URL会导致线程死掉，但是行不通，因为速度太慢。当时的IDE也缺乏对多线程调试的一些支持。而且即便有支持，可能也不太适合这种情况。后来因为种种原因，那个程序就不了了之了。

这本书中SOA治理的思想给了我一些启发：我们需要关注服务执行的健康状况，包括服务执行的时间。例如，我们可以进行这样的改动：

在每个线程领取URL时，记录一个时间戳。在它完成这个URL处理时，再记录一个时间戳。再利用一个线程，对未完成的URL定时检查它的健康程度。如果在很长的一段时间内它还没完成，那么它就有问题。这样我们可以找到嫌疑URL。我们可以对这种URL单独测试，看看是否因为程序的原因，不能处理这样的URL。或者，我们可以把对应的线程任务杀掉，直接跳过这些有问题的URL。

如果您和我一样，是一名开发人员，学习一些SOA的思想是很有帮助的。我们可以在程序中设计一些机制，支持运营维护和故障分析，这正是SOA的一部分内容。

IT运维部门需要SOA。业务部门需要SOA。企业高层需要SOA。设想一家经营固话业务的电信公司，通过兼并和重组，拿到了一个移动网络。公司最需要的是什么？就是SOA。

这个移动网络上跑着多少应用？多少中间件？多少数据库？多少操作系统？多少服务器？它们的使用状况如何？它们由谁提供技术支持？它们是什么配置和版本？它们有哪些参数可以调整？它们支持着怎样的业务流程？它们支持着怎样的业务数据模型？它们提供怎样的QoS？它们在安全性和可伸缩性方面存在哪些风险？

SOA参考框架帮助我们提出这些问题。提出问题比解决问题更重要，真的。企业应该认真考虑向SOA迁移。