微服务中是否仍存在与Java进程之间的通信？

Question

Actually I'm about to realise some microservices architecture. Having three different processes running on one Windowns machine I'm about to let them communicate with each other.

Is this in the paradigma of Microservices? Or am I'm pushing this too far?

Context : A system which lets a frontend webapp execute tools/scripts which lie on a backend machine on a server.

Components :

• REST Interface (with which the webapp frontend does communicate)
• ToolBoxExecutor (with which the REST Controller is communicating)
• ToolSyncer (which is being "triggered" by the ToolBoxExectutor to refresh all Git Repositories for the tools)

Those three components do not have a big load of logic - but I still want them NOT to act as Services of the REST Controller - just for the sake of "microservices". I want them all to be three independent java applications.

Am I on the right track?

Answer 1

High-level

Am I on the right track?

No. By focusing on an emerging, as-yet loosely defined architectural style as your end objective, you are completely missing the point. It is well worth considering whether the design and architectural properties considered characteristic of a microservice architecture will be a good fit for your project, but you're turning that backwards. It is a red flag to me that you claim to be making design decisions "just for the sake of 'microservices'".

Analysis with respect to microservices

As for whether you are in fact building something in microservices style (for whatever that's worth to you), let's look at microservices characteristics as described at martinfowler.com :

Componentization via Services

As far as I can tell from what you've presented, you are indeed doing this, but all I really have to go on is that you have pieces running in several different, cooperating processes. That's not all there is to being a component, nor to operating as a service. Each component should have a well-defined job and a well-defined interface, independent of implementation characteristics to the greatest extent possible. Components should rely only on each others' defined interfaces to interoperate.

Organized around Business Capabilities

What you've presented appears to run directly contrary to this characteristic, being organized around technology layers instead of business capabilities.

Products not Projects

This is more a lifecycle management consideration than an architectural one. It's unclear whether you're operating in this way, but the way you couch your question makes me inclined to guess not.

Smart endpoints and dumb pipes

Whether your design has this characteristic is unclear, but it seems likely, given the nature of the components as you are defining them.

To the extent that it might be more appropriate to consider the whole thing as one microservice (see "Organized around Business Capabilities" above), the fact that it has a REST interface is a good sign.

Decentralized Governance

This is another characteristic that seems a bit larger-scale than your efforts alone. To the extent that you seem to have mostly free rein to design and build your product, it seems like you are indeed benefiting from decentralized governance. Inasmuch as you seem to be a one-man team, however, that doesn't really apply internally within the scope of the development effort you are undertaking.

Decentralized Data Management

It's unclear whether your plans have this characteristic, or even to what extent it applies to you.

Infrastructure Automation

It's again unclear how well this characterizes your intentions, and to what extent it is even within your area of concern.

Design for failure

You've said nothing relevant to this characteristic.

Evolutionary Design

It's unclear to what extent your proposed architecture exhibits this characteristic. I'm inclined to guess not very much, though.

Overall

What you're describing does not seem to be on the scale to which the term "microservices architecture" applies, as Martin Fowler describes it. There are certainly aspects of this paradigm that you could apply at your scale; some of these you do seem to apply, others you seem not to apply, and others I cannot evaluate with respect to your architecture overview.

I don't think you're well served by trying to bring all these characteristics to your scale, and certainly the extent to which you do so is not a good metric for the quality of your design. It may be that you want to design your product to work within a larger microservices context, but that puts few constraints on you; indeed, the freedom that offers you is one of the main advantages of the microservices approach.