处置这一成绩的最好办法是，让开发人员可以轻松地在他们的机器上运转数据库（作为 Docker 容器），并投资创立 SQL 脚本来设置形式和初始主数据。这些 SQL 脚本应该保存在版本控制中，并像维护任何其他代码一样停止维护。
4. 版本控制托管平台缺乏可见性我曾与一个客户停止协作，事先，他们的版本控制系统中有 1000 多个仓库。他们运用的是 Gitlab 版本控制平台。他们有 5 个产品，每个产品都由多个微效劳组成。
我问他们的第一个成绩是协助我们了解哪些效劳及其各自代码库是产品 A 的一部分。他们的首席架构师不得不花一天时间弄清楚一切产品 A 的仓库。一天过去了，她还是不能确定能否弄清楚了一切效劳。
处置这个成绩的最好办法是，从一末尾就以某种方式对你的微效劳停止分组，这样，你就可以随时了解产品的生态系统。Gitlab 提供一种办法来创立一个组，然后在其中创立项目仓库。Github 并没有组功用，因此你可以运用主题或命名商定来完成它。
我团体更喜欢 mono repos，由于我发现他们真的很方便。我遇到的大少数开发人员都以为它是一种反形式。我赞同 Dan Lua 的观念，他提到了 mono repo 的以下益处：
简化的组织
简化的依赖关系
工具
跨项目变更
5. 效劳没有明白定义大少数团队并不知道什么应该被视为效劳。关于终究是什么构成一个单一的微效劳，人们对此存在很多混杂的看法和困惑的概念。
让我们举一个例子，假定你的运用顺序具有相似插件的架构，在这个架构中，你集成了多个第三方效劳。每个集成应该是一个微效劳吗？我看到很多团队，都在为每个集成创立一个微效劳。随着集成数量的添加，这种状况很快就会失控，以致于无法管理。这些效劳通常太小，以致于将它们作为独自的进程运转，会添加更多的开支。
我以为，哪怕只拥有大批的大型效劳，总比提供太多的小型效劳要好得多。我将从创立一个效劳末尾，该效劳对业务组织中的整个部门停止建模。这也契合 DDD（范围驱动设计， Domain Driven Design）。我将一个域分为子域和有界上下文。有界上下文表示公司外部的一个部门，如财务部门和营销部门。你能够以为，这会招致大型效劳的出现，你是对的。
随着知识阅历越来越多，你可以转向代表更小成绩的细粒度微效劳。你能运用单一责任准绳（Single Responsibility Principle）来了解微效劳能否变得过大，做的事情能否过多。
然后，你可以将它分解成更小的独立效劳。任何效劳都不应该直接与其他效劳的数据库通讯。他们应该只经过已发布的合同停止沟通。在 Microservices.io 网站上，你能了解更多关于按子域形式分解的内容。
https://microservices.io/patterns/decomposition/decompose-by-subdomain.html
我也遵照了 Backendlore 文档中提到的建议。
https://github.com/fpereiro/backendlore
这个建议可以协助将效劳限制在效劳通讯上，而效劳通讯是微效劳系统功用低下的首要缘由。假设两条信息相互依赖，那么它们应该属于同一个效劳器。换句话说，效劳的自然边界应该是其数据的自然边界。
6. 代码重用策略不明白我曾经和一个客户协作，该客户在他们一切基于 Java 的微效劳复制了四个与特定成绩相关的 Java 文件。因此，假设在该代码中发现 bug 的话，就需求将其修复运用到一切中央。我们都知道，在时间紧迫的状况下，我们会错过将更改运用于一个或多个效劳。这样会糜费更多时间，添加挫败感。
这并非说开发团队不懂正确的事情。但是，按照组织结构，人们总是默许采用复杂且容易出错的做事方式。
正确的办法是，运用像 Bintray 或 Nexus 这样的工件管理器，并在那里发布依赖项。然后，每个微效劳都应该依赖于这个库。你需求构建工具，以便在发布新版本的库时，一切的微效劳都应该停止更新和重新部署。
运用微效劳并不意味着你不应该运用迄今为止对我们有用的最佳实际。你需求对工具停止投资，使微效劳的晋级变得更容易，这样人们就不必这样做了。
在没有适宜的工具和自动化的状况下，运用微效劳会招致灾难。
7. 多言语编程设计我发现团队运用多种编程言语、多种数据库、多种缓存，并以最佳工具的名义停止任务。一切这些都在项目初始阶段起作用，但随着你的产品投入消费，这些选择末尾显露“本色”。
缘由就像我们在构建 JavaSpringBoot 运用顺序，但是我们看法到 Java 占用更多的内存，而且功用也很差，所以我们决议改用 Node.js。在我的上一次义务中，我向团队解释说他们的推理才能很弱。
1.Note.js 比 Java 功用更好
假设你的任务负载是基于 I/O 的，Node.js 通常会表现的更好。但在任何计算密集型的任务负载上，Java 都胜过 Node.js。经过照应式范式（reactive paradigm），你可以运用 Java 为 I/O 任务负载提供更好功用。在 I/O 任务负载方面，Spring Boot Reactor 的功用相当于 Node.js。
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html
https://blogs.sap.com/2018/08/03/spring-boot-reactive-vs.-node.js-in-sap-cloud-platform-reflection-on-throughput-measurement/
2.Node.js 比 Java 消耗更少的内存
在一定水平上，这是正确的说法。Java Spring Boot 运用顺序并不像大少数想象的那么蹩脚。我在一个 Spring Boot Java 微效劳上运转了负载测试，内存消耗依然没超过 1 GB。你可以经过 OpenJ9 JVN，限制对类途径的依赖，并经过调优默许的 JVM 参数来优化 Java 内存应用率。此外，在 Java 中还有 Spring Boot 的新替代品，如 Micronaut 和 Quarkus，它们消耗的内存相当于 Node.js。
3.Node.js 比 Java 效率更高
这取决于编写代码的开发人员。运用静态类型和静态剖析工具的 Java 可以协助在开发作命周期的早期发现成绩。
大少数状况下，这完全取决于上下文。假设你的开发人员还不够成熟的话，那么无论你运用什么编程言语，你开发的都将是蹩脚的产品。
我建议一家组织要发布一个团队可以运用的言语列表。我以为 2~3 就是个很不错的数字。另外，要列出一种言语比另一种言语更适宜的理由。
在选择一门言语前，你应该思索以下一些成绩：
找到成熟的企业软件开发人员有多容易？
重新培训开发人员掌握新技术有多容易？我们发现 Java 开发人员可以相对容易地学习 Golang。
初始团队之外的开发人员贡献、转移和维护其别人编写的代码有多容易？
就工具和库的方面而言，生态系统有多成熟？
这不只仅局限于编程言语，也适用于数据库范围。假设你的系统中曾经有了 MongoDB，那么你为什么要在生态系统中运用 ArangoDB 呢？它们都主要是文档数据库。
要一直思索运用多种技术的维护和操作方面。
8. 人员的依赖性 (责任编辑：admin)