面向新手的实用 SOA
我对 SOA 世界来说是个新手。 因此，我正在研究一些“SOA 框架/技术”，并尝试了解如何利用它们来构建高度可扩展的（Facebook 类）网站。
我在这里试图解决几个“难题”：
- 可组合性（+管理依赖项、发布/订阅）、
- 服务的语言独立性、
- 可扩展性和可扩展性。 性能
- 高可用性
我研究了一些满足上述标准子集的技术：
- Thrift - Facebook 的交叉-platform RPC 平台
- WCF - 支持 SOAP、JSON 和 REST，因此可以认为它是语言可互操作的。 生成可用于生成 java 代理的 WSDL 文件。
- Microsoft DSS - 刚刚将其包含在我的调查中，但它似乎并不相关，因为它是高度状态驱动且特定于 .NET 的。
- Web 服务
现在，我了解了如何从上述内容中获得可组合性和语言独立性的某些方面。 但是，我还没有找到关于如何使用上述/其他工具实现可扩展性和高可用性的具体信息（不是嗡嗡声）。 最后，我提出了我的问题：
如何利用 SOA 技术来解决我上面定义的难题？在哪里可以找到这方面的技术指南？ 我寻找的不仅仅是系统图，而是实际的库、代码示例、API...
I am a total newbie to the world of SOA. As such, I am looking at some "SOA frameworks/technologies", and trying to understand how to utilize them to build a highly scalable (Facebook class) website.
There are several "pains" I am trying to solve here:
- Composability (+ managing dependencies, Pub/Sub)
- Language-independence of services
- Scalability & Performance
- High availability
I looked into some technologies that answer a subset of the above criteria:
- Thrift - Facebook's cross-platform RPC platform
- WCF - supports SOAP, JSON & REST, so it can be considered language-interoperable. Generates WSDL files that can be use to generate java proxies.
- Microsoft DSS - just inclued it in my survey, but it doesn't seem relevant as it is highly state-driven and .NET specific.
- Web Services
Now, I understand how I get some aspects of composability and language-independence out of the above. But, I haven't found much concrete information (not buzz) about how to use the above / other tools for scalability and high availability. So finally I get to my question:
How does one leverage SOA technologies to solve the pains I defined above? Where can I find technical guides for that? I am looking for more than just system diagrams, but rather actual libraries, code samples, APIS...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为这个问题更多地与所涉及的概念有关，而不是与工具有关。 问题答案：
您真的需要支持这种类型的负载吗？ 设置与特定场景相关的适当性能/负载/互操作性目标。 如果您确实需要支持这种类型的负载，我建议您找一个处理过该负载的人。
如果最终可能是针对负载的，请识别有界上下文并设计具有 SOA 思维方式的交互。 剩下的事情就是保持代码整洁，在代码库中使用 TDD、松散耦合、集中集成测试等。 有了好的代码，如果以后需要分离系统的各个部分，就会容易得多。
I think the question has more to do with the concepts involved than the tools. Answers to the items:
Do you really need to support that type of load? Set appropriate performance/load/interoperability targets that relate to the specific scenario. If you really need to support that type of load, I recommend you get someone on board who has dealt with it.
If it is something for a load that might eventually be, identify the bounded contexts and design the interaction between those with a SOA mindset. Keeping the code clean is all you have to do for the rest, use TDD, loose coupling, focused integration tests, etc in your code base. With good code, if you later need to separate pieces of the system, it will be a lot easier.
Amazon 首席技术官 Werner Vogels 对服务和架构说了一些有趣且相关的内容：
There are interesting and relevant things said about services and architecture by Amazon's CTO - Werner Vogels:
IDesign.net 有一堆很棒的 WCF 下载。
IDesign.net has a bunch of great downloads for WCF.
值得一看：http://www.manning.com/davis/ ？
Worth a look at: http://www.manning.com/davis/ ?
查看 Mule 项目，该项目捆绑了 CXF 服务堆栈以及提供 RESTful 替代方案的 Mule REST 包。 我想您会发现它解决了您所有的难题，并且文档和发行版中有很多示例。
Check out the Mule project which bundles the CXF services stack and also the Mule REST pack which provides RESTful alternatives. I think you'll see it addresses all of your pains and there are lots of examples in the documentation as well as the distribution.
我可以推荐一本书：Springer Verlag 出版的《Enterprise Service Oriented Architectures》。
May I recommend the book: Enterprise Service Oriented Architectures published by Springer Verlag.
这里的所有建议都很好，但除非您确实需要，否则不要担心。
专注于构建人们真正喜欢的可用的、功能性的应用程序。 当你开始遇到问题时，就开始处理瓶颈。
您永远无法预见应用程序失败的所有方式，因此您如何判断 [[在此插入技术]] 是否是您的答案？
All of the advice here is well and good, but don't worry about it until you really need to.
Focus on building a usable, functional application that people really like. When you start running into problems, then start handling bottlenecks.
You will never be able to foresee every way an application will fail, so how can you tell if [[insert tech here]] is your answer?