代码之家 › 专栏 › 技术社区 › user7127000

对于这样的工作流,应该使用什么设计模式?

soa microservices workflow architecture design-patterns

1

user7127000 · 技术社区 · 8 年前

          (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

我想提供以下微服务:

(B) 文件下载器

在第一种情况下,它可能看起来像

A: (1),(2) ====> B:(3) ====> C:(4i),(4ii),...,(4N)

A: Get latest commit
B: Download all files by commit
C: Process single file

然后X将拥有/执行

决定并行处理下载的文件

哪个是更好的实施?

Is new commit? part意味着我保存提交的记录,这样我就可以判断我检查的内容是否是我以前没有检查过的。 谁应该保存犯罪记录?它应该考虑在A的存储中还是单独的“工作流存储”?

2 回复 | 直到 8 年前

1

Christian Bongiorno 8 年前

我的方法是 Chain of Responsibilities 其中每个节点负责检查条件或执行作业

“新提交?”{true |错误}D
如果是真的,“做事”停止?(访客?)

因此,每个节点都有可能执行一个终止函数(这可能/可能不会返回结果;me中的功能主义者说应该这样做)。

从编码的角度来看,它可能是这样的:

interface Responsibility<I> {
    fun apply(context:I) : Unit?
}

class GitRepo{
    val files = setOf<URI>()
    val commiters = setOf<String>()
    fun hasNewCommit() = true

}

abstract class Chained<I,N>(protected val next:Responsibility<N>) : Responsibility<I> {


}
class CheckCommited(next:Responsibility<Set<URI>>) : Chained<GitRepo,Set<URI>>(next) {
    override fun apply(gr:GitRepo) = when(gr.hasNewCommit()) {
        true -> next.apply(gr.files)
        false -> null
    }
}
class DownLoadFiles(next:Responsibility<Set<URL>>) : Chained<Set<URI>,Set<URL>>(next) {
    override fun apply(uris:Set<URI>) {
        next.apply(uris.map { downLoad(it) }.toSet())
    }
    fun downLoad(uri:URI): URL {
        return uri.toURL()
    }
}

class NotifyPeople(val people: Set<String>) : Responsibility<Set<URL>> {

    override fun apply(context: Set<URL>): Unit? {
        people.forEach {  context.forEach { sendMail(it.toString()) }}
    }

    private fun sendMail(email: String) {

    }
}

val root = CheckCommited(DownLoadFiles(NotifyPeople(setOf("joe@company.com","suzy@someplace.other"))))

2

1

jgauffin 8 年前

那不是微服务。这就是pico服务和imho,它们是小型化的方式来激励微服务所需的所有额外维护和管理。在他精彩的演讲中 GOTO Conference 2014

为了简单起见,可以使用基于消息的体系结构,每个内部服务订阅来自其他内部服务的消息。

例如,当下载完成时,可以发送 FileDownloaded 事件来自 FileDownloader FileProcessor 已在订阅。在这种情况下,它们之间也没有紧密的耦合。

messaging library