到目前为止，我的开发应用程序计划在网络和移动设备上提供，因此我决定将其作为微服务进行。
到目前为止我的应用程序可以执行的操作如下所示：
如上所述，我应该闯入多少服务？ 我不确定将所有操作拆分为服务，例如注册服务/登录服务，还是将其分组，因为用户服务是正确的方式。
另一个问题，当我单独拆分服务时如何获取作者的文章数据以在我的网站上呈现？ 构建新的代理服务，在文章服务中获取文章数据然后之后在用户服务中获取作者数据？或者，不需要代理服务，只需简单地获取文章数据，然后在我的Web应用程序控制器中创作数据。
答案 0 :(得分：1)
到目前为止，我的开发应用程序计划在网络和移动设备上提供，因此我决定将其作为微服务进行。
根据您的应用程序将支持多个平台这一事实选择微服务（MS）方法是不可取的。如果您之前从未处理过微服务架构，那么构建具有强大上下文边界的模块化整体结构可能更好。通过这种方式，可以更容易地专注于编程和实现应用程序，稍后您可以逐步将monolith分解为微服务，一次一个（即，您从具有低流量的模块开始，如注册服务）。此外，直接进入微服务，除非你正在为自己的经验或乐趣做一个项目，适合过早优化的类别。有关Monolith第一种方法的更多信息，Martin Fowler写了一篇关于它的great article。
如上所述，我应该闯入多少服务？
[我正在回答拆分后端系统并通过API从前端调用MS。] 注册和登录应该是一个不同的服务，因为通常注册使用频率较低（一旦用户注册，他只是从现在开始登录）而不是登录.Facebook登录将签署MS。 查看文章也比发布，编辑或删除（您拥有博客平台或Facebook）更频繁，因此一个MS将提供数据来查看文章，一个MS将用于发布，编辑或删除文章。
当我单独拆分服务时，如何让作者在我的网站上呈现文章数据？
MS artchitecture最常见的方法是多语言持久性，其中每个MS都有自己的数据库，包含它实际编辑或更新的表。然后，您可以通过调用其API来访问其他MS的数据（查看文章服务在其Article表中还有作者ID，然后您使用作者ID调用用户服务/注册服务以获取其完整信息）虽然这提供了更紧密耦合的架构。
另一种选择是以事件的形式存储数据，其中新用户注册是一个事件，存储在用户服务MS数据库中并发送到某个队列或主题，其他服务可以注册以从其接收事件并存储他们数据库中的事件。这样您将复制数据，但将具有更松散耦合（和异步）的体系结构。 Google事件驱动的数据管理有关此方法的更多信息。