我想打破我的整体微服务，但我仍然坚持下去。需要建议
I want to break my monolithic to microservices but I'm still stuck on it. Need advise
到目前为止，我开发的应用程序计划在 Web 和移动设备上可用，因此我决定将其作为微服务来实现。
下面列出了我的应用到目前为止可以执行的操作：
- 注册（电子邮件、用户名、密码，password_confirmation）
- 登录（电子邮件、密码）
- 使用 Facebook 登录（如果数据库中存在电子邮件，则自动登录，或者当数据库中不存在电子邮件时，创建新记录然后自动登录）
- 查看文章
- Post 篇文章
- 编辑文章
- 删除文章
如上操作，我应该破解多少个服务？ 我不确定将每个操作拆分为服务（如注册服务/登录服务）或将其分组为用户服务是正确的方法。
另一个问题，当我单独拆分服务时，如何获取作者的文章数据以呈现在我的网站上？ 构建新的代理服务文章服务中的文章数据然后在用户服务中获取作者数据？或者，不需要代理服务，只需获取文章数据，然后在我的网络应用程序控制器中获取作者数据。
So far, my developing application is planned to be available on web and mobile so I decided to do it as microservice.
基于您的应用程序将支持多个平台这一事实来选择微服务 (MS) 方法是不可取的。如果您以前从未处理过微服务架构，那么构建一个具有强上下文边界的模块化单体应用可能会更好。这样一来，您就可以更轻松地专注于编程和实施应用程序，然后您可以逐渐将整体分解为微服务，一次一个（即，您从流量较低的模块开始，例如注册服务）。此外，直接进入微服务，除非你是为了自己的经验或乐趣而做一个项目，否则就属于过早优化的范畴。有关 Monolith 优先方法的更多信息，Martin Fowler 写了一篇关于它的 great article。
As actions above, how many services should I break into?
[我在拆分后端系统和通过 API 从前端调用 MS 的上下文中回答。]
注册和登录应该是不同的服务，因为通常注册的使用频率低于登录（一旦用户注册，他就从现在开始登录）。Facebook 登录将与登录 MS 一起使用。
看文章也比post编辑删除（你有博客平台或者Facebook）更频繁，所以一个MS提供数据看文章，一个MS用来post , 编辑或删除文章。
when I split services separately how can I get articles data with the authors to render on my sites?
最推荐的 MS 架构方法是多语言持久性，其中每个 MS 都有自己的数据库，包含它实际编辑或更新的 tables。然后你可以通过调用它的 APIs 来访问其他 MS 的数据（查看文章服务在它的文章 table 中还有作者的 ID，然后你调用用户 service/sign使用作者 ID 的服务以获取其完整信息），尽管这提供了更紧密耦合的架构。
另一种选择是以事件的形式存储数据，其中新用户注册是一个事件，该事件存储在用户服务 MS 数据库中并发送到某个队列或主题，其他服务可以注册以从中接收事件并将事件存储在他们的数据库中。这样您将复制数据，但将具有更松散耦合（和异步）的体系结构。 Google 事件驱动的数据管理以获取有关此方法的更多信息。
到目前为止，我开发的应用程序计划在 Web 和移动设备上可用，因此我决定将其作为微服务来实现。
下面列出了我的应用到目前为止可以执行的操作：
- 注册（电子邮件、用户名、密码，password_confirmation）
- 登录（电子邮件、密码）
- 使用 Facebook 登录（如果数据库中存在电子邮件，则自动登录，或者当数据库中不存在电子邮件时，创建新记录然后自动登录）
- 查看文章
- Post 篇文章
- 编辑文章
- 删除文章
如上操作，我应该破解多少个服务？ 我不确定将每个操作拆分为服务（如注册服务/登录服务）或将其分组为用户服务是正确的方法。
另一个问题，当我单独拆分服务时，如何获取作者的文章数据以呈现在我的网站上？ 构建新的代理服务文章服务中的文章数据然后在用户服务中获取作者数据？或者，不需要代理服务，只需获取文章数据，然后在我的网络应用程序控制器中获取作者数据。
So far, my developing application is planned to be available on web and mobile so I decided to do it as microservice.
基于您的应用程序将支持多个平台这一事实来选择微服务 (MS) 方法是不可取的。如果您以前从未处理过微服务架构，那么构建一个具有强上下文边界的模块化单体应用可能会更好。这样一来，您就可以更轻松地专注于编程和实施应用程序，然后您可以逐渐将整体分解为微服务，一次一个（即，您从流量较低的模块开始，例如注册服务）。此外，直接进入微服务，除非你是为了自己的经验或乐趣而做一个项目，否则就属于过早优化的范畴。有关 Monolith 优先方法的更多信息，Martin Fowler 写了一篇关于它的 great article。
As actions above, how many services should I break into?
[我在拆分后端系统和通过 API 从前端调用 MS 的上下文中回答。] 注册和登录应该是不同的服务，因为通常注册的使用频率低于登录（一旦用户注册，他就从现在开始登录）。Facebook 登录将与登录 MS 一起使用。 看文章也比post编辑删除（你有博客平台或者Facebook）更频繁，所以一个MS提供数据看文章，一个MS用来post , 编辑或删除文章。
when I split services separately how can I get articles data with the authors to render on my sites?
最推荐的 MS 架构方法是多语言持久性，其中每个 MS 都有自己的数据库，包含它实际编辑或更新的 tables。然后你可以通过调用它的 APIs 来访问其他 MS 的数据（查看文章服务在它的文章 table 中还有作者的 ID，然后你调用用户 service/sign使用作者 ID 的服务以获取其完整信息），尽管这提供了更紧密耦合的架构。
另一种选择是以事件的形式存储数据，其中新用户注册是一个事件，该事件存储在用户服务 MS 数据库中并发送到某个队列或主题，其他服务可以注册以从中接收事件并将事件存储在他们的数据库中。这样您将复制数据，但将具有更松散耦合（和异步）的体系结构。 Google 事件驱动的数据管理以获取有关此方法的更多信息。