我们使用API（CakePHP，MySQL）和与其连接的单独的前端应用程序（javascript）运行各种托管的组合服务。 API（我们将其称为Content API）是非常单一的，因为它处理身份验证，存储和检索所有内容，发送电子邮件，基本上是服务器端的所有内容。我们的团队很小，我们的服务相对较小（成千上万的用户）。我们目前正在单个Amazon EC2实例上运行，但希望在不久的将来进行扩展。
我们将要构建一个分析系统，该系统将包括一个显示花哨图形的前端，以及一个存储事件并为上述图形提供数据的API。
现在我正陷入困境：我应该创建一个单独的Analytics API，还是将其功能与我们现有的Content API集成？
我一直在阅读微服务的优势，并且由于分析是一个如此独特的功能，我倾向于认为它值得拥有自己的API。但是...
我们正在处理的数据并不太疯狂。我们说的是GB，而不是TB。同样，分析数据的结构也很漂亮（事件类型，日期时间，user_id，content_id等）。另外，我们将不会搜索文本字符串。所有这些使我认为关系数据库比Elasticsearch更合适。由于我已经了解MySQL，因此我也倾向于将MySQL用于分析。
此外，由于我已经知道CakePHP，因此我也倾向于将CakePHP用于Analytics API。尽管我仍然愿意使用更轻量级的PHP框架。
现在，正如我提到的那样，Analytics API将需要存储事件（网页浏览量等）。但它也需要来自我们的Content API的数据（用户名，文件名等）。此外，我想使用身份验证，这也由我们的Content API处理。因此，如果我们的Google Analytics（分析）前端向我们的Google Analytics（分析）API发出请求，则Google Analytics（分析）API必须对我们的Content API发出一个或多个请求，然后才能将其汇总在一起。至少要对用户进行身份验证，还要收集Google Analytics（分析）图所需的部分数据。
经常提到的微服务的优点之一是，您可以独立处理微服务，添加和更改功能，甚至可以迁移到全新的平台上。另一个是可伸缩性：您可以扩展一个微服务，而不必扩展另一个。
但是，当一个微服务需要另一个微服务中的数据时（我的情况就是这样），这些优势难道不是被否定的吗？每当我在Content API上更改端点时，我都需要考虑一下Analytics API是否正在使用该端点。没有单元测试可以解决这个问题。而且，随着我们的Google Analytics（分析）API的使用量增加，我不能仅仅扩大Analytics（分析）基础设施的范围，因为Content API也会受到更多的攻击。</ p>
所以我想知道，在我们的情况下，采用整体方法是否更有意义？还是我看不到的微服务方法有好处？
答案 0 :(得分：1)
首先，这是任何微服务实现中的典型场景。而且您的想法都没有错。是的，这些都是劣势;这将意味着更多的工作和更多的延迟，因为https休息api调用将比JVM内部进行的调用慢得多。
此外，您可以对微服务进行独立维护并不总是正确的。自动存在依赖性。
说了这么多，我们都知道人们因为一个最大的优势而正在转向微服务……这是无限的规模……如果假设您是亚马逊公司，那么您就必须以任何成本实现规模化。这可能是更高的延迟数。.然后微服务是唯一的解决方案。.这些天，我们在云上甚至还有256 GB的RAM盒..因此，在达到Amazon级之前，您应该能够处理扩展。.
但是，如果假设您的组织出于任何原因决定将微服务作为前进的方向，那么这是您在微服务中开发Google Analytics（分析）的合适时机...因为，我们总是会有很多交付..我们将一直在管道中发布如此多的功能。.我们将永远没有时间将现有产品重新设计为微服务。.因此，无论您开发什么，都应将其作为微服务进行开发。通过这种方式，您的团队也可以学习东西，并且学习的东西不会太多，风险和时间的最佳利用。
这是基于我的个人经验。