Let's say I have a workflow like this
(1) Check for latest commit in a GitHub repo
|
|
(2) Is new commit?
/ \
No / \ Yes
/ \
/ \
End \
\
\
(3) Download all files
/ | \
/ | \
(4i) Process file i . Process file N
\ . /
\ . /
\ . /
\ . /
\ . /
End
and I want to have the following microservices:
- (A) Commit Checker
- (B) File Downloader
- (C) File Processer
My question is whether each of these microservices should be a link in a sequential workflow, or whether these microservices should just contain functionalities and a separate "omniscient" microservice conducts the workflow.
In the first case it might look like
A: (1),(2) ====> B:(3) ====> C:(4i),(4ii),...,(4N)
where each link is writing a message in a queue that gets picked up by the next link.
Because (2) is in A, that means that A is making a decision about whether to invoke B. I guess you could then say that the services are tightly coupled.
In other implementation I've suggesting, there would be a separate service X that performs the control flow and simply plugs in data to A, B, C, which would perform single tasks like
A: Get latest commit
B: Download all files by commit
C: Process single file
and then X would own/execute the logic of
- (2), i.e. deciding whether to terminate the workflow or do the next step
- Deciding to have the downloaded files processed in parallel
Which is better implementation?
Another question I have is about storage. The Is new commit?
part means that I keep a record of commits so I can tell whether what I checked is one that I haven't checked before. Who should keep the record of commits? Should it be considered in A's storage or a separate "workflow storage"?
Aucun commentaire:
Enregistrer un commentaire