Java微服务、JVM Params、k8s和Docker的配额和其他
FROM some-container-reg/openjdk-runtime:11-hotspot
# prepare build
COPY --chown=1001:1001 build/install/svc-example .
COPY --chown=1001:1001 config.yml .
# exposing port(s)
EXPOSE 8080
# setting entry point...
ENTRYPOINT ["bin/svc-example", "server", "config.yml"]
resources:
limits:
cpu: 250m
memory: 288Mi
requests:
cpu: 100m
memory: 192Mi
env:
- name: JAVA_OPTS
value: "-XX:MaxRAMPercentage=75.0"
容器请求等于来自java应用程序本身的工作量。限制被定义为请求加上96mi的偏移量。通过这样做，我希望确保除了JVM-Heap之外的需求有足够的资源来正常工作--metaspacesize、CodeCache、...。
另外，通过应用-xx:maxrampercentage=75.0，在容器部署中定义java_opts，这为JVM定义了75%的总内存限制。为什么不在-xx:xmx=192mi中定义显式堆限制呢？有关详情，请参阅下面的连结。
https://bugs.openjdk.java.net/browse/jdk-8186315
- 我上面的建议正确吗？
- 如何确定实现低成本部署的限制？
- 是否需要对JVM应用附加的参数，如
gc或maxMetaspacesize，以防止内存使用超过限制？ - 我是否也需要为Dockerfile定义JVM-Args？更清楚地说，Docker的JVM和Java-Microservice的JVM是相同的？
暂时还没有答案
-
我想知道每种方法的利弊是什么。例如，在graphQL中包含所有内容似乎有点多余，因为我们将在每个服务中复制模式的部分。另一方面，我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗？我们都没有使用GraphQL的经验，所以这里是否有一些明显的利弊我们可能会遗漏？ 提前道谢！
-
更准确地说，在我看来，BDD测试应该验证业务逻辑，而且只验证业务逻辑。在许多框架中，BDD测试场景是由滑板持有者用DSL创建的。BDD测试倾向于收敛于排他性的“不了解基础设施”的实践。另一方面，集成测试应该验证解决方案是否与目标基础结构匹配（它们由DevOps完成？），并且只与基础结构匹配。当业务功能通过微服务“分布”时，您应该模拟BDD测试环境（应该是本地环境）中的几乎所有内容（infra和bu
-
问题内容： 我们有几个微服务项目，每个项目都是独立的（在单独的spring boot服务器上运行，公开其余服务，使用单独的DB模式…） 我们使用Maven管理依赖关系。 有一个父pom将每个微服务声明为模块是一个好主意吗？因此，有助于管理公共依赖项（例如，在每个项目中都使用lib servlet-api witch，将其全部删除并仅在父pom中声明） 问题答案： 多模块父pom的“问题”是，没有复
-
我们有几个项目是微服务，每个项目都是独立的（在单独的spring boot服务器上运行，公开rest服务，使用单独的DB模式…） 我们使用maven来管理依赖关系 让父pom将每个微服务声明为模块是个好主意吗？因此有助于管理公共依赖项（就像每个项目中使用的lib servlet-api女巫一样，将其全部删除并仅在父pom中声明它）
-
微服务作为一种软件架构风格正在获得牵引力，它将更好地支持持续交付，为快速部署和关注点分离提供模型。 Vert.x 3和Vert.x-Apex为构建微服务提供了一个有趣的模型。如其中一个例子所示，一个简单的verticle可以公开一个HTTP服务，因此REST服务是可用的。垂直绑定它自己的tcp端口。 当扩展到多个微服务来支持一个完整的应用程序时，您最终会有许多选择。对于哪种风格能够最终支持连续交付
-
我的公司有一个消息传递系统，它以JSON格式发送实时消息，它不是建立在AWS上我们的团队试图使用AWS SQS接收这些消息，然后用DynamoDB存储这些消息，我想用EC2读取这些消息，然后保存它们，有什么更好的解决方案吗？或者怎么做我没有很好的经验