如何在团队中处理基于单个网关的微服务? [英] How to work on single gateway based microservice in a team?
问题描述
我们正在使用Jhipster开发基于微服务的应用程序.为此，应同时运行不同的组件，即服务注册表，UAA服务器，网关和其他不同的服务.要在我的PC上运行所有这些组件，它将消耗所有资源(16 GB的Ram).但是，其他开发人员的PC上没有足够的资源，这就是我们面临的问题，即团队继续开发的原因. 因此，我们正在寻找解决此问题的方法，以提高开发团队的效率.
We are developing microservice based application using Jhipster. For that, there are different components should run at the same time i.e, service registry, UAA server, Gateway, and other different services. To run all these components on my PC it consumes all the resources (16 GB of Ram). However, other developers, they don't have sufficient resources on their PC, which is the reason we are facing the problems continues development in the team. So we are seeking some options for this problem to get efficiency over our development team.
当前，如果有人要在应用程序上添加/更改功能，则需要同时使用微服务和网关(用于前端). 那么，在这种情况下，会发生什么?假设有多个开发人员在开发环境中同时处理网关和服务. 他们将如何调试/测试?他们必须分别部署网关吗?
Currently, if someone wants to add/change features on the application, he needs to work with both microservice and gateway(for the frontend). So, in this case, what happen? suppose multiple developers are working on gateway and service at the same time in the development environment. How are they going to debug/test? do they have to deploy gateway individually?
我们计划在自己的VPS服务器上部署微服务，并在不久的将来用于生产Heroku，kubernetes，jenkins，cloudfoundry.
We are planning to deploy microservices on our own VPS server and in near future for the production heroku, kubernetes, jenkins, cloudfoundry can be used.
如果我做错了，请纠正我，是否有更好的选择来顺利进行开发?
Correct me if I am wrong and is there any better option for smooth development?
我读过萨姆·诺伊曼(Sam Neuman)的《微服务》(Microservice)一书，其中提到了在开发过程中基于单个网关的应用程序的问题.现在，我对Jhipster如何解决这个问题感到非常好奇.
I had read Sam Neuman's Microservice book that the problem of the single gateway based application while development.Now I am very curious about how Jhipster came to resolve this problem.
推荐答案
在我看来，您正在尝试使用微服务，因为它是一个整体.微服务架构中最重要的功能之一是能够独立地在每个微服务上工作的能力，这意味着您无需运行整个基础架构即可开发功能.想象一下，Netflix的一名开发人员需要在其PC上运行数百种微服务来开发一项功能，这真是太疯狂了.
It seems to me that you are trying to work with your microservices as it was a monolith. One of the most important features in the microservice architecture is the ability to work on each microservice independently, which means that you do not need to run the whole infrastructure to develop a feature. Imagine a developer at Netflix who needs to run several hundreds of microservices on their PC to develop a feature - that would be crazy.
微服务与所有权有关.通常，不同的团队在不同的微服务或一组微服务上工作，这对构建良好的测试设计非常重要，以确保每当所有微服务都作为一个内聚系统启动并运行时，一切都会按预期进行.
Microservices is all about ownership. Usually, different teams work on different microservices or some set of microservices which makes it really important to build good test design to make sure that whenever all the microservices are up and running as one cohesive system everything works as expected.
所有这些，在开发微服务时，您不必依赖其他微服务.相反，您最好模拟与其他微服务的所有交互，并编写测试以检查您的微服务是否在做其必须做的事情.我建议您 wiremock ，因为它对Spring具有开箱即用的支持开机另一个原因是 Spring Cloud Contract 也支持它，使您能够使用另一种强大的技术，称为消费者驱动的合同"，这可以确保在任何给定时间都不会破坏两个微服务之间的合同.
All that said, when you are developing your microservice you don't have to rely on other microservices. Instead, you better mock all the interactions with other microservices and write tests to check whether your microservice is doing what it has to do. I would suggest you wiremock as it has out-of-the-box support for Spring Boot. Another reason is that it is also supported by Spring Cloud Contract that enables you to use another powerful technique called Consumer Driven Contracts which makes it possible to make sure that contract between two microservices is not broken at any given time.
这些是集成测试(它们在微服务级别上运行)，由于模拟，它们具有非常快的反馈，另一方面，您不能保证在运行所有模拟后您的应用程序可以正常工作.这就是为什么应该有另一类更粗粒度的测试，也就是端到端测试.这些测试应该针对整个应用程序运行，这意味着所有基础结构都必须启动并正在运行，并且可以满足您的请求.这种测试通常由CI自动执行，因此您不需要在PC上运行所有微服务.在这里，您可以检查API网关是否可以与其他服务正常运行.
These are the integration tests (they run on a microservice level) and they have a very fast feedback because of the mocks, on the other hand, you can't guarantee that your application works fine after running all of them. That's why there should be another category of more coarse grained tests, aka end-to-end tests. These tests should be running against the whole application, meaning that all the infrastructure must be up and running and ready to serve your requests. This kind of tests is usually performed automatically by your CI, so you do not need all the microservices running on your PC. This is where you can check whether you API gateway works fine with other services.
因此，理想情况下，您的测试设计应遵循以下测试金字塔.您拥有的粒度测试越多，应将它们保留在系统中的数量就越少.如果说比例，没有灵丹妙药，粗略数字是:
So, ideally, your test design should follow the following test pyramid. The more coarse grained tests you have the less amount of them should be kept within the system. There is no silver bullet if to speak about proportions, rough numbers are:
- 单元测试-65％
- 集成测试-25％
- 端到端测试-10％
附言:很抱歉，您没有直接回答您的问题，我不得不在测试中使用类比，以使其更加清晰.我只想说通常，您在开发时不需要照顾整个系统.您需要照顾自己的特定微服务，并模拟与其他服务的所有交互.
P.S: Sorry for not answering your question directly, I had to use the analogy with tests to make it more clear. All I wanted to say is that in general, you don't need to take care of the whole system while developing. You need to take care of your particular microservice and mock out all the interactions with other services.
这篇关于如何在团队中处理基于单个网关的微服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
