我想在这里解决几个“痛苦”：
>可组合性(管理依赖项,Pub / Sub)
>服务的语言独立性
>可扩展性&性能
>高可用性
我研究了一些能够回答上述标准子集的技术：
> Thrift – Facebook的跨平台RPC平台
> WCF – 支持SOAP,JSON和amp; REST,因此它可以被认为是语言可互操作的.生成可用于生成Java代理的WSDL文件.
> Microsoft DSS – 刚刚在我的调查中包含它,但它似乎并不相关,因为它是高度国家驱动和.NET特定的.
>网络服务
现在,我理解如何从上面得到可组合性和语言独立性的某些方面.但是,我没有找到关于如何使用上述/其他工具实现可伸缩性和高可用性的更多具体信息(不是嗡嗡声).最后我得到了我的问题：
如何利用SOA技术来解决我上面定义的痛苦？我在哪里可以找到技术指南？我正在寻找的不仅仅是系统图,而是实际的库,代码示例,APIS ……
解决方法
>理解并内化bounded context.保持不相关的部分将其重要性分开,以便在不同的服务上实现真正的重用.相关技术对此没有帮助,您可以在适当的上下文中分离应用程序,您可以适当地重用不同的服务.
>基于已知协议的清晰通信端点允许使用不同技术实现不同的部分
>让操作像基于不同协议的独立操作一样流动,为您提供了许多可以添加层的地方.是使用大量资源的整个过程的特定子过程,服务器不能再使用它,只需移动到单独的服务器.负载不断增长,并且该服务器不再使用它,添加额外的服务器和负载平衡.您还有更多机会使用缓存和连接池.
>拥有一个需要始终可用的关键子流程,添加服务器以便进行故障转移.有一个需要一直“可用”的整个过程,使用队列可以在以后处理.
你真的需要支持这种类型的负载吗？设置与特定方案相关的适当性能/负载/互操作性目标.如果你真的需要支持这种类型的负载,我建议你让一个人在船上处理它.
如果它是最终可能的负载,则识别有界上下文并设计具有SOA思维模式的那些之间的交互.保持代码清洁是您需要做的其余工作,在代码库中使用TDD,松耦合,集中集成测试等.有了良好的代码,如果您以后需要分离系统的各个部分,那将会容易得多.
