当构思出一个大产品或一个小型软件开始发展成为一个大问题时，我应该选择哪种开发路径？ 我应该从头重写所有内容还是继续“历史悠久的”传统？ 无论如何，是否值得修改建筑的概念？
您好，Khabrovites！ 我叫康斯坦丁（Konstantin），我是一个相当大的系统的首席开发人员，该系统曾经是一个实验。 一个小型的PHP网站实际上是在“膝盖”上创建的，当然是一个整体。 随着时间的流逝，该站点不断增长并遇到了许多问题，解决这些问题时提出了一个问题，“然后又如何？”。
整体还是微服务？ 选择什么？ 在我看来，这两种方法之间的基本区别在于，整体意味着处理用户请求的集中化周期，而微服务则意味着分散的处理。 两种方法的共同优点和缺点是众所周知的，并且不止一次列出（例如，
在此处 ，
此处或
此处 ）。 但是，没有那么明显的因素影响体系结构的选择。
- 加载全职员工 。 随着产品的快速发展，大量任务堆积如山，无法在可接受的时间内解决-每个人都很忙。 而且，如果这种“障碍”是单一的，那么扩大开发人员队伍是没有意义的。 显而易见的解决方案是外部承包商（公司或自由职业者）。 但是，粗略地说，如何在不冒将其变成OpenSource的风险的情况下使他们使用产品的一部分？ 在使用微服务的情况下，此任务更容易解决。
- 潜水的难度 。 产品越大，新员工适应它所花费的时间就越多。 尤其是如果代码具有许多不同的默认值（是的，好的文档可以使该过程容易得多，但是如果不存在，则更好吗？）以及针对个别特殊情况的自定义。 从这个角度来看，处理一个小的独立部分要比立即处理整个产品容易得多。
- 高峰负荷的资源 。 在我的实践中，有一种情况是服务器上的负载有时会增长到不可接受的值（并且特别是RAM耗尽，激活了交换，服务器变成了一段时间），在其余时间的空闲时间中（RAM负载不超过30％） ） 这样的高峰不规则地发生并且停顿了很长时间。 在整体式情况下（我们认为没有地方可以优化代码），只有新服务器与整个系统的副本进行连接以节省负载，这才省下来。 对于微服务，您可以组织一个处理队列（当然，这仅适用于快速且不可预期的时间紧迫的操作，例如卸载Excel表）。
- 在后台执行任务 。 该因素以何种方式“动摇船”取决于其大小和复杂性。 通常，一个整体和一个计时器（cron）就足够了。 但是，如果任务开始成群地聚集，也会出现问题。 已经有必要平衡cron任务。 微服务极大地促进了这种情况。
- 跟踪的复杂性 。 在微服务的情况下，对铁维护的要求增加了-应该在哪里配置，配置什么以及如何配置。 Monolith-粗略地说，是所有节点的某些设置，微服务-设置取决于节点上运行的特定微服务的要求。
- 资格要求 。 动物园的技术越多（如果系统是微服务，它通常会增长），对正规员工的技能和知识的要求越高。 毕竟，如果有改进或问题，他们必须应付。 或者需要更多的专业人员来覆盖整个堆栈。
有什么需要选择的吗？ 这个游戏值得吗？ 我认为绝对值得。 但是，人们必须冷静地对待这个问题。 否则，某些问题将被其他问题所取代。
以我为例，当站点停止“适应”一台服务器的资源时，出现了一个转折点。 然后决定根据我认为最好的选择（混合动力）重写系统。 在“混合案例”中有针对产品开发的
一般建议 。 但我想补充一些建议。
在设计启动器整体时，需要立即放置进一步连接外部服务的可能性。 立即建立组件间通信，就好像这些组件已经（或几乎已经）是“外部服务”一样。 特别是如果它们是资源密集型的。
立即考虑使用缓存和数据存储（数据库和文件）的策略。 例如，共享一个用户的会话。
最重要的是不要急于求成。 我自己为一个好的项目得出了以下公式：“有效的系统就是平衡的系统”。 特别是，这体现在以下事实中：在微服务中，我只取出内核中逻辑上隔离的大片段。 然后，只有满足至少一个条件：
- 需要进行负载限制和预测，由于任务执行而导致的时间延迟并不重要
- 隔离将大大提高生产率。
通过这种方法，我们得到了一个系统，其中95％的功能位于内核中，而5％的功能位于微服务中。 但与此同时，核心仅占总负载的60％。 同时，您可以保证单个服务器上的负载不超过临界值。
因此，如果仅在真正需要的情况下使用微服务（从产品的特定尺寸来看），则微服务是好的（而不是因为时尚或“因为它很酷”）。 有许多成功地作为整体生存的大型
产品 。 但是有时候，一个整体无法解决问题...
谢谢你