I try to work with go-kit (gokit.io) and to build real-work application with it.
I look through examples. These examples are great. But I do not understand how to do services to service communications / data transfers in go-kit framework.
I can see "real-world" shipping app, but I do not understand how it could be "real world" micro-services. I can see in sources that, for example, they build the booking service just passing foreign repositories into service
type service struct {
cargoRepository cargo.Repository
locationRepository location.Repository
routingService routing.Service
handlingEventRepository cargo.HandlingEventRepository
}
and later they get data from repositories (this repository belongs to foreign micro-service) just calling the method:
locationRepository.Find(...)
Could someone please explain me:
how to build micro-service to micro-service communications in go-kit framework? Just show me the way / pattern, please. I do not understand it at all.
I see it as they just share direct access to data. But in real world micro-services, I expected that micro-services will communicate to each other to get needed data. And I do not understand how to do it in go-kit framework.
I'm the author of the shipping example. Sorry for not seeing your question earlier.
This particular example needs a bit of explanation. It is an example based on tactical patterns from Domain Driven Design, which means that we need to understand what we are talking about when we're referring to a service.
There are application services that deal with the use cases offered by the application, e.g. booking.Service. There are domain services that reside in the domain layer and provides your domain with concepts that aren't necessarily bound to a domain object. In the shipping example, routing.Service is a domain service whose implementation actually queries another application, in this case it talks to this routing service.
Application and domain services are merely ways of organizing our code. Putting it differently, these services communicate within a process, while microservices typically communicate over a network using some form of common transport, e.g. JSON, gRPC and so on.
Coming back to your question, what I believe you are looking for is the implementation of the routing.Service which you can find here.
The proxy service used here is explained under Client-side endpoints on this page, and is used to make requests from your application to another.
If you want more detail, I wrote a blog post on the subject a while ago.
Related
Lets say I have multiple domain services for book, review and customer with a database each and a BFF as proxy/mediator for the client. The BFF brings all data together and communicates with non-domain-services. There is also an external API where some data is fetched from or sent to:
I am facing some issues here:
isolation: The book model is distributed over several services which also implies a lot of request/response mapping. Ergo: If the book domain model changes I have to change a lot of stuff, although, according domain modelling or microservices should rather prevent developers from adjusting multiple services/interfaces.
external dependencies: Unfortunately, in the real life scenario it is even worse, because the book service is implicitly highly coupled to the external API, meaning that, if the book model of the external API changes, the book service will probably change too.
validation: AFAIK validation should belong to the domain service. In the real life scenario however, I have to access author, customer and book at once, in order to do business validation.
Can you give me some direction how to deal with these issues?
I'm new with this but in case if we have fronted + few different microservices I just don't get why do we need any of them to communicate with each other if we can manipulate between their data via axios on frontend. What is the purpose of event bus and event-driven architecture in the case if we use both frontend and backend microservices?
Okay, for my example I'm using 5 microservices. There are 2 of them:
Shopping cart
Posts
And I want to access posts microservice directly, pass their data through the event bus, so the shopping cart microservice would have its information. The reason is that posts and shopping cart both have different data bases, so is a good example doing this that way, or just through frontend with axios service?
What you are suggesting could be true for a very simple application, which hardly even needs an architecture such as microservice. It is clear why services need communication:
some services are not even accessable (for various reasons such as security) in client, so a change in them must be initiated in other backend services with such priviledge
some changes are raised in backend services and not client, e.g. a cronjob for doing some task
it would question reusability as you must consider the service to be used by not only client, but in any environment
what would happen if you want your services to be used by public, what if they do not implement part of the needed logic intentionally or by mistake
making client do everything could be so complex and would reduce flexibility
some services such as authentication are acting as a supporting mechanism to ensure safety (or anything other than main logic), these should be communicated directly by the service needing them
As for second part of your question, it depends on several factors like your business needs & models, desired scalability, performance, availability, etc. so the right answer or in another say, the answer that fits would be different.
For your problem, using event bus which is async would not be a good solution as it would hurt consistency in your services. Instead synchronous ways like a simple API call in your posts service would be a better idea.
Should Microsercices be reusable?
With reusable I do NOT mean sharing Domain specific Models.
I mean should a microservice created for one application be reuseable in another application?
Is it sufficient if they are reusable within an application?
What is the best way to decouple microservices.
From my point of view as soon a microservices calls another microservice it is tightly coupled, means it can not easily (without modifications) be extracted and put into another microservice application that does not have the same service it refers to/from.
To decouple them, in my opinion, there are following ways:
microservice A needs to talk to the other microservice B with a
standard contract eg. a specfic protocol.
another Microservice C acts as a gateway and asks microservice B for the data and passes it as input to microservice A.
A concrete example for nr. 2 would be:
Coupled:
client -> API GateWay -> UserProfileService -> Authorization Service
Decoupled:
Client -> API Gateway -> Authorization Service -> API Gateway -> UserProfileService
Am I right assuming that this all boils down to the goal of the microservice? There is no wrong and right?
Are there any other strategies i'm missing to decouple a microservice?
I think the responses you're likely to get will represent opinions more than answers, but I'll go ahead and give mine!
The literature for microservices has long said, "decouple, decouple, decouple", but frankly I don't find this to be reality. When someone has created a useful API that would empower the functions of your own (auth, payments, and obviously databases come to mind), is it wrong to suggest that those need to be run alongside yours? Most people don't go through complicated, logic-filled gateways in order to make payments via Stripe or send text messages via Twilio, so why should privately hosted APIs be any different?
It is great to design your own service to be a reusable, easily consumable/deployable component. That shouldn't mean it can't have dependencies, but rather that we should be mindful of the bloat those dependencies introduce. This mindfulness is something devs should practice whenever they introduce dependencies, regardless of whether they are app packages or dependent services/APIs.
**disclosure: I build and run a framework/platform, Architect.io, to help cloud-native teams collaborate and build upon each others services. I've seen first-hand how company's like Facebook use similar tactics to enable service re-use and consumption, and wanted to build a microservices dependency resolver for the general public.
It completely depends on what microservice you are building. For ex; say you are building an email notification service. That can be reused by different applications. Another example say you are building a recommendation system. It's very specific for a single application. It hardly makes sense to design it in such a way that it can reused in different applications.
Choose according to the context. There is no right way. It all depends on the application.
I am a newbie in Microservices, having theoretical knowledge. I want to make a small application in Microservices. Can anyone please help me with the idea of how to implement microservices?
Thanks in Advance!!
You can create something like a currency conversion app with three microservices like these:
Limit service;
Exchange service;
Currency conversion service.
Limit service and currency conversion service can communicate with the database for retrieving the values of the limits and currencies conversion.
For more info check github.com/in28minutes and look after a microservice repository.
No matter how perfect the code of your microservice is, you may face issues with support and development if the microservice architecture doesn’t work according to certain
rules.
The following rules can help you with microservices a lot:
You have to do everything by yourself because you do not have any Rails and architecture out of the box that can be started by one command. Your microservice should load libraries, establish client connections, and be able to release resources if it stops working for any reason.
It means that being in the microservice folder and having made the 'ruby server.rb' command (a file for starting a microservice) we should make the microservice do the following:
Load used gems, vendor libraries (if used), and our own libraries
Use the configuration (depend on the environment) for adapters or classes of client connections
Establish client connections (permanent connections are meant here). As your microservice should be ready for any shutdowns, you should take care of closing these client connections at such moments. EventMachine and its callback mechanism helps a lot with this.
After that your microservice should be loaded and ready for work.
Incapsulate your communication with the services into abstractly named adapters. We name these adapters based on their role (PubSub, SMSMessenger, Mailer, etc.). This way, we can always change the inner implementation of these adapters by replacing the service if the names of our classes are service agnostic.
For example, we almost always use Redis in our application from the very beginning, thus it is also possible to use it as a message bus, so that we don’t have to integrate any other services. However, with the application growth we should think about solutions like RabbitMQ which are more appropriate for cases like ours.
If your code is designed in such a way that your classes are coupled with each other, do it according to the dependency inversion principle. This will help your code to avoid issues with lib booting.
Learn more here
You can try splitting an existing Monolithic application to gain perspective on microservice architecture.
I wrote this article, which talks about splitting a Django App into microservices. Hope it helps.
I am in the process of learning about microservices and there's one thing that I can't seem to figure out and I can't find any resources that give me a direct answer to this. The question is:
Do microservices involve only business logic and database interactions
or do they involve UI components like JS, CSS, HTML as well ?
There really isn't a notion of what tiers are included in a microservice itself, however generally speaking, when referring to microservices most of the time you're referring to some back end based app. That begin said - there are companies out there - two that I've talked to directly that are building "microapps" - basically the backend service, facade and a portlet like interface that can be plugged into a federated portal through a layer of orchestration.
For the Java folks - think fully encapsulated JSR-268 like components that are run as independent processes running within a portal itself.
A microservice can be a complete application including its own UI, business logic and data.