I have a stateless service on multiple nodes with dynamic endpoints.
I want to use the ServiceProxy with their dynamic endpoint like this one:
localhost:32010+dd1d0a27-1dec-49db-8960-83bf001355be-131329828855327547
How do I use ServiceProxy to connect to the specific node instance using that endpoint?
I'm instantiating the ServiceProxy like this:
ServiceProxy.Create<T>(new Uri("fabric:/XXX));, which will only find one of the instance nodes. I want to specify the node to connect to via the endpoint. How do I do that?
There is no way to use Service Remoting to connect to a specific instance of a Stateless Service. You can only target specific partitions/replicas for Stateful Services.
Look at this SO answer.
Your options are basically:
Change to HTTP communication
Redesign as a Stateful Service
Another thing you might want to ask yourself is why you want to target a specific instance or node? Is it because you wan't some performance benefit? Do you have some other type of affinity from the client to the service you want to target?
Related
I have two services running in my Service Fabric cluster. Let's assume they are Service A and Service B, both of them are Stateless Services. I am using the dns service method to communicate between A and B and the entry point in B is an api which has a route. Now this route is also publicly accessible since I have exposed port 80 publicly for that service. And even though someone who is trying to access this api will have to send the appropriate Auth tokens, I still don't want to be able to anyone outside the cluster to access this api. Is there any other way I can achieve what I am trying to do? I know another way is to use the service proxy pattern but for some reason that did not work for me.
We are developing microservices in NodeJS and deploying them to an Application server. These services run on random port which is set in config file programmatically. I know these services could be managed using service discovery like Eureka / Consul and similar. However, is there a way to manage them without using any service discovery.
However you call it, you will need a central place where services will need to register their host and port (and deregister when they shutdown gracefully), so that others know how to consume them. You can use a database (SQL/noSQL), Eureka, Consul, anything that will give you "put data" and "get data" capabilities.
Benefit of solutions like Eureka and Consul are built-in health checks and removing service from the registry if it fails them.
Assume you want to deploy 2 apps of which one provides some API to the second application.
With services I'd just bind the service (or declare it as dependency in my manifest) to my application and hence get the information regarding host, port and credentials passed to my application (e.g. via env variables in node.js). Is there a similiar mechanism for application to application "communication"?
So far my approach is to use a RabbitMQ service (or any message broker/queue) which both applications are bound to and which I then use for cross-app communication.
Thanks!
Using a message broker, as you do, is definitely a viable solution. This allows for asynchronous communication. Yet you will have to take care of authentication yourself, as opposed to app <-> service communication, where authentication/authorization is established through through cloudfoundry service binding.
Another way would be to use a service registry for this. Both apps would register with the service registry and be able to discover each other.
You could try spring cloud service registry (Eureka) or consul. As for your message broker solution, this will not generate credentials for your apps, as a cloudfoundry service binding does.
From your use case, for microservice to microservice discovery, you need Spring Cloud Services and Eureka.
I don't have much experience on nodejs. But some googling, will give you some articles. Here's one that may help you - https://www.npmjs.com/package/eureka-js-client
This article will give you an overview from Java and Spring perspective - https://spring.io/guides/gs/service-registration-and-discovery/.
I would like to inject my own service between two services using dbus to communicate.
I would like to control what goes to the other service without doing source modifications to the two daemons currently communicating.
Is this even possible?
[edit] A comment made me realize that I was maybe not clear enough. Both services are on the same host.
If you have the possibility to modify what bus connection at least one of the services connects to, you could use a proxy for the bus and intercept and interact with the traffic between the two services.
E.g.: https://github.com/Pelagicore/dbus-proxy
I'd like to implement micro service architecture on CF (run.pivotal.io) and have problems with creating my private backend services.
As I see I have to options at deployment: with and without route.
With route my services becomes public which is ok for my public site and my public REST API, but I don't want it for my backend services.
Without route I don't see how should I do service discovery.
What I found already:
Use VCAP_APPLICATION env variable and create my own service discovery (or use something like Eureka) based on that. Does this give me always a valid IP:PORT? No matter what DEA my app is running it is reachable on this IP:PORT by other apps on other DEAs?
Register my backend app as a service and bind it, than use VCAP_SERVICES. I'd like to do this but only found documentation about registering services outside CF. Is there a simple way to bind my own app as a service?
So what would be really nice is to be able to mark an app as private but still assign a host and domain to it, so (only) my other apps could call it though CF load balancers but it would be protected from the public.
Answers inline...
As I see I have to options at deployment: with and without route.
This depends on the Cloud Foundry installation and how it's configured. On PWS, you cannot talk directly between application instances. It's a security restriction. You have to go through the router.
With route my services becomes public which is ok for my public site and my public REST API, but I don't want it for my backend services.
The best you can do here is to add application level (or container level, if you prefer) security to prevent unauthorized access.
If you don't want to do password based authentication, you could do IP based filtering. On PWS, we just added a service with Statica. You can use that to send your outbound traffic through a proxy which will assign a static IP to that traffic. You could then restrict access to your app to only the Statica IPs.
Without route I don't see how should I do service discovery.
If you remove the route, you can't sent traffic to the app.
Use VCAP_APPLICATION env variable and create my own service discovery (or use something like Eureka) based on that. Does this give me always a valid IP:PORT? No matter what DEA my app is running it is reachable on this IP:PORT by other apps on other DEAs?
You'd probably need to use this enhancement. It was added to support this type of deployment. However this will only work on Cloud Foundry installation where the networking restrictions between application instances have been relaxed. Normally you cannot talk directly between instances.
Register my backend app as a service and bind it, than use VCAP_SERVICES. I'd like to do this but only found documentation about registering services outside CF. Is there a simple way to bind my own app as a service?
You can create a "user provided" service. Look at the cf cups command. It lets you create a service with an arbitrary set of parameters and data. This could contain the URLs for your services. Once you create the service, you can bind it to any number of apps.