I'm quite a newbie to microservices architecture. I'm referring to one of my clients projects with microservice architecture. It has one of the service as Notification
Order ->(talks to)-> Notification client(as a lib) -> calls api from - > Notification service.
I don't really understand the purpose of having a client in between, where in it has a few exceptions handled for hitting the api. I understand, microservices communicate via api gateway but I feel Notification Client is just an addon. I tried to figure out the terminology used for this kind of implementation but in vain.
Please help me understand this use case.
It may feel that the client is redundant if Order service is the only microservice that is consuming the APIs. But considering the notification service is getting used by a few more microservices having a notification client as a lib makes sense. The reason is,
The client lib will wrap all the API calls and their implementation
so that other services can simply call it just like a method.
Other services don't have to write REST client for notification service when it wants to
make use of the APIs.
Same client lib can be shared by other microservices without actually
writing code to call the APIs.
Any changes/fixes made to the notification service can be cascaded to other services by simply changing the version of the client lib.
Related
I am currently working on a project which has a GraphQL service that takes care of handling all client requests and communicates with other microservices as needed be. This GraphQL service is the only service exposed to the client, basically kind of like an API gateway.
Taking this into account, I was wondering if all microservices are required to have authentication/authorization handlers, as well as input and data validation. Since these microservices can only be accessed by the GraphQL service and are never exposed to the public, is there any risk to not performing these mentioned tasks on them? Can't the main GraphQL service simply take care of all the authentication, authorization and input validation and then proceed to only send requests to the microservices having these steps occurred successfully?
What I know so far is that:
Api gateway: Is fixed entry point that manage north/south communications.
Service Mesh: Is a side-car proxy that manage inter-service communication east/west.
service registry: Is a database of services, their instances and their locations.
All sound clear, but when I try to put all things together, I am confused:
Most of the service mesh/api gateway vendors say that they provide
access control mechanisms and other similar mechanisms, are these mechanisms an overlapping
functionalities between both concepts, or they have different scope
and goals?
Assume all Api gateway, Service Mesh and Service registry are deployed together:
Does the api gateway forward the request directly to the service, or
it communicate with service proxy?
Do I have to register a service twice, one in the gateway and one in
the service registry? or how to integrate the service registy with api gateway?
Finally Until now it seems for me the all concepts purely serve different purposes so they all necessary, but they overloaded with other functionalities. Is it possible to integrate them in meaningful way? or is there a reference architecture that I can follow?
Because no one posted an answer and based on my continuous reading, I was able to grasp a basic idea of how all components should work together, I will not answer directly to question, rather I will try to make things more clear:
API Gateway or Service Mesh are nothing just proxies, but with that said they are proxies of different types.
API Gateway is a front-proxy or edge-proxy, through it you communicate with the world. so in your architecture you may have an API Gateway running with or without Service Mesh beeing deployed.
To register your services in your Gateway you have two options(maybe more):
Static registration: using configuration file or using the Admin API of the API Gateway you are using, this is similar of how KONG work.
Dynamic registration: usually this is done by integrating your Front-proxy (API Gateway) with some other Service Registry/Discovery tool. you can accomplish that for example using Envoy and consul.io.
Using only Front-proxy (without service mesh) It is hard to do health monitoring, Logging and let all service know if it’s pointless to try to contact a down service(Circuit breaker).
Now, if you need to isolate your services from the topology of the network, or you need to provide a set of functionality around each of your services such as, mentoring, Logging, retries, circuit breaker..etc, then you can accomplish that by deploying a process (beside each service) that proxies all the out and in requests to your service. This process what we call a sidecar proxy. All the sidecars proxies usually run the same code, but they are configured differently.
Finally: The combination of the edge-proxy (API Gateway ) and the sidecar proxies forms what we call a Service Mesh. And obviously all proxies can utilize the same service registry/discovery mechanism.
I am fairly new in microservices architecture. I've been trying to build a microservices stack using Spring Boot, Spring Cloud and Netflix OSS libraries.
I want to know what is the correct way and place to store session.
Here is an overview of the infrastructure that I created:
OAuth2 backed Authorization/Authentication Server
UI Service (Spring Boot, Front end service)
Backend Service-1
Backend Service-2
Redis Server to store session and other cachable data
Discovery Server (eureka)
Currently, I'm trying to store session in Redis by configuring UI service to perform it. It seems to be working fine, although I haven't had the chance to try it for multiple service instances. However, I'm already having serialization/deserialization issues while developing.
By the way, trying to store the session on front end app is the correct place to do or it should be done in Authorization/Authentication service as authentication is processed in that service?
Here is my Session config in UI service (front end service)
#Configuration
#EnableRedisHttpSession
public class SessionConfig extends
AbstractHttpSessionApplicationInitializer {
public SessionConfig() {
super(RedisConfig.class);
}
}
To sum up, I'm expecting to achieve and use best practices on this project. Your kind assistance would be appreciated.
The idea of a general server side user session and a microservices style architecture don't go together well. The reason being that you are likely to break the separation of concern that you use separate the domain boundaries of your services.
Remember, every service is supposed to service a specific domain problem autonomously - including all required data persistence. So for example if there is anything to remember for a users connected devices you would do that in the one service that is responsible for those device connections and nowhere else. The service would be responsible for processing those request and persisting any status that the devices require. Similarly when there is anything to remember about he users authorization you would do that in the authorization service.
And regarding the question to use Redis or not - In a microservices architecture the choice of storage system would be up to the service architect. Maybe one service stores its data in a relational database, maybe another uses a key-value-store and yet another may use an event queue system or a time series database.
So in summary you have to ask yourself what your session really is used for and make the corresponding services responsible to persist that information in a domain specific way. (If you give some more details in your question about this, I can give you my opinion).
There is no doubt that API gateway should be the edge server to outside world.We are wondering that should we use API gateway in the communications between the microservices?
You can definitely use API gateway lets say for that matter (netflix -zuul) for inter-service calls, only thing of concern for you would be,
what happens when you start versioning your services, assuming you'll be using eureka as a naming server from which zuul gateway will fetch all registered services, but now in your case zuul will get two instances of your service (version previous and verison next) and ribbon will load balance the requests between the two, this point is already thoughtfully covered in
How to route in between microservices using Spring Cloud & Netflix OSS
Basically if you are familiar with BlueGreen Deployment model, implementing that would be a problem, surely there are proper workarounds for that as in defining/registering some metadata along with your previous and latest versions which would later be picked by ribbon client to route accordingly
I am having 4 different micro-services in my application. The technology stack that I am using for the development of applications is SBT stack(Scala,Akka and Play web framework). For external clients to communicate with my micro-services, I have security mechanisms such as authorization and authentication of users using Oauth protocol, White-listing Allowable Http Methods and performing input validation. However, I wanted to know 2 things
1) Is it necessary to implement security mechanisms when one microservice calls another microservice internally
2)And if required, how to implement security on messages passed from one micro service to other. Any help would be highly appreciated. Thanks in advance !!!