实施SOA，技术不是问题，最大的问题还是管理和沟通(协作)。
实施SOA的话，我们需要重新构建一套基础架构，提供统一的端点配置管理、异常管理、健康监控、契约协作平台等。不然到最后的配置和管理将会很混乱。
我们不需要更多的服务器，但我们需要更合理的分配服务器。而且整个系统的部署架构可能随着时间的迁移不断调整的，合并压力小的服务，拆散压力大的服务。怎么做负载均衡，这都是一直调整的。
实施SOA需要开发人员有更好的意识，包括协作意识，包括架构意识。当然，也需要架构师能够参与到每个项目中去，心中对业务有大局观。
配置可能是复杂的，需要有工具来确保这个复杂的过程。服务和网站怎么配置是很重要的事情，需要架构师和开发人员讨论决定，不是说随便放上去能用就可以。
在做架构的时候要站在较高的角度来看，眼光要长远，暂时的性能问题不一定是问题。按照网络/磁盘/内存/CPU的层次来考虑。很多时候SOA和性能是有冲突的，就像不能一味觉得ORM性能不好就不去使用。考虑80/20原则，任何东西满足了80的应用就达到了目的，剩下的20进行特殊处理。
暂时就写这些，大家拍砖。
补充几点：
从服务契约设计上来说，应该让这个契约尽可能独立，不依赖于其它的契约。服务的调用过程不能依赖于服务本身的状态，应该在任何情况下服务的作用不会由环境所变。
虽然说是内部实施，但最好数据契约的类型是标准类型，通用类型，原生类型，方便以后做开放API的时候真正实现对外的服务。其实SOA强调松耦合性，因异构平台协作的需求产生，强调一切基于消息，无关服务平台。
SOA的实现包括业务分析、契约规划、服务管理、消费者管理、文档管理、配置管理、迭代整合等重要步骤，不是说我要建立A契约就建立，我要消费A契约就消费，要体现在管理中。我一直觉得SOA不是组件升级到服务这么简单，软件开发流程、管理流程、设计分析方法、配置管理都会有巨大的改变，前期准备要充分。
在建立前期需要制作完成一个基础的架构供开发人员使用。比如说是不是需要扩展VS内建的WEB引用，使得生成的客户端代理包括异常处理、端点配置(从配置服务中获取)等内容。非业务相关异常的收集和发送等工作应该是自动的，无需编码。由于调用的复杂性，服务可能还会调用服务，在部署的时候配置问题很难察觉，所以其中的异常处理非常重要。
项目完成后的代码审阅需要对项目中用到的服务进行逐一检查，如果有改变需要在拓扑图(推荐有专门管理软件来维护这个拓扑图，并且还能检查各个节点的健康状态)中进行修改。必要的话还可以为每一个节点实现信任机制，得不到信任的消费者将不能消费。甚至这个工具可以和SHAREPOINT结合，也提供文档的管理。
最理想的方式是实现服务的自动部署，全部依靠管理工具来完成，因为在服务器上安装Windows服务，需要复制文件、卸载原来的服务、安装新的服务、服务运行账户的配置，如果服务达到上百个的话，部署的压力也比较大。
最后，什么是SOA?个人觉得SOA是提供了系统级的松散组合和重用的基于消息的整合方案。
文章来源于领测软件测试网 https://www.ltesting.net/
