出于个人和大学研究的原因，我正在考虑使用面向服务的架构构建一个简单的 CRM。它的意义只是为了解释架构本身，而不是商业用途。
我正在考虑实现一个提供简单分析服务和客户服务(用户存储、个人评论和其他一些东西)的 CRM。
我正在设计的架构定义:
- WebGUI(其他服务的客户端)
- AnalyticsService(接收数据、分析和收集数据的服务)
- CustomerCareService(使用 RESTful API 应用 CRUD 操作的服务)。
每个服务都有自己的数据库，完全独立于其他服务。它们公开了一个公共(public)接口(interface)。该接口(interface)当然必须提供某种身份验证，以拒绝未经授权的请求。
我想在这种架构中解释的优点是可以让所有事物独立并能够将它们组合起来以提供新服务(例如，如果有一个 OrderService 来处理订单，那么它很容易与使用公共(public) API 的客户)。对我来说最大的优势是构建使用这些服务的其他客户端很容易。
我不知道什么是好的身份验证方法，可以很容易实现，我也不确定如何制作这个 API(使用 XML 或带有 GET/POST 数据的普通 REST API)。我曾与 Amazon、PayPal 和其他公司 API 合作过，他们似乎使用 REST 服务(paypal 使用丑陋的 _cmd GET 参数，而 Amazon 使用更好的 URI)来知道该怎么做，但是阅读一些关于 SOA 的东西似乎人们也使用XML。当然，我还需要考虑到 Web 界面必须能够识别登录用户、获取权限( token 或其他任何内容)并将其与服务一起使用以显示信息。
所以我不确定 SOA 是不是我真正构建的那种架构……是 SaaS 而不是 SOA？
我认为最好使用 RESTful 应用程序，使用 JSON 或类似的东西来实现它(我不是 XML 的忠实粉丝，我觉得它太冗长了)。
为清楚起见，我在这里列出我的问题:
我有大约 3 个月的时间来做这件事，所以我不能做一些真正复杂的事情(除了这对于单个程序员来说是不现实的)。
我知道 Python(WSGI 框架)、Ruby on Rails、C/C++ 和其他语言(.net 除外)，我想在 Linux 环境下开发它(MySQL 或 Postgres，如果您有任何建议，甚至可以使用 NoSQL正确的选择)，我还可以将这些服务独立程序的几种语言结合起来。
我想在这里有一些好的观点和一些好的建议。
谢谢!
最佳答案
我会将 SaaS 定义为一种商业模式，而不是一种架构；然而，就像所有业务领域需求一样，它会影响系统架构，但它本身不会。您定义的内容是面向服务的架构必不可少的。
您的陈述“独立并能够将它们组合以提供新服务”是建议 SOA 的基本非功能设计要求。
良好的 SOA 实现是关于定义良好且灵活的接口(interface)，以及非常明确的职责划分。然而，它很难被规范。证据在吃；它是否提供了灵活的重用。我的建议是花时间阅读 SOA 设计模式资源，并了解与使用的适当上下文相关的定义特征。然后应用单一职责原则适当的抽象级别。引用文献(Domain) Space Based Architecture是一种 SOA 元模式。
关于授权，我建议遵循服务方法，使用分布式目录服务系统，如开放 LDAP，并注意服务提供者和用户拥有自己的凭据是完全合理的，您可以使用公私 key 签署消息。
主要建议是学习和借鉴他人的经验:
关于web-services - 面向服务的架构建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10105093/