一个可以自我进化的微服务框架

你是否遇到过这样的框架，它非常简单又是轻量级的，很容易上手，然而当你的项目变得复杂的时候它能自我进化成功能强大的重量级框架，而不需要把整个项目重写? 我是从来没见过。

先让我们来看一下项目的生命周期。通常，当一个新项目开始时，我们不知道它能持续多久，所以我们希望它尽可能简单。大多数项目都会在短时间内夭折，所以它们并不需要复杂的框架。然而，其中有一些击中了用户的痛点并受到欢迎，我们就会不断地对它们改进，使它们变得越来越复杂。结果就是原来简单的框架和设计已经远远不能满足需求，剩下的方法就是重写整个项目，并引入强大的重量级框架。如果项目持续受欢迎，我们可能需要多次重写整个项目。

这时一个能自我进化的框架就展现出优势。我们可以在项目开始时使用这个轻量级框架，并只在确实需要时才将其进化为重量级框架， 在这个过程中我们不需要重写整个项目或更改任何业务逻辑代码，当然你需要对创建结构（struct）的代码（也叫程序容器）做一些修改。但这个修改比起修改业务逻辑或重写整个项目不知要容易多少倍。

这听起来太棒了，但有这样的东西吗？很长一段时间以来，我都认为这是不可能的，直到近竟然找到了一个。

去年，我创建了一个基于清晰架构（Clean Architecture）的框架，并写了一系列关于它的文章。请查看"清晰架构（Clean Architecture）的Go微服务" 。它使用工厂方法设计模式来创建对象(结构)，功能非常强大，但有点重。我希望能把它改的轻一些，这样简单的项目也能使用。但我发现任何强大的框架都是重量级的。没有一个框架是轻量级的但同时又非常强大，正如鱼与熊掌不可兼得。我在这上面花了不少时间，后终于找到了一个方法，就是让框架能够自我进化。

解决方案

我们可以将一个项目的代码分为两部分，一部分是业务逻辑（Business Logic），其中所有调用都基于接口，不涉及具体对象（结构）。另一部分是为这些接口创建具体对象(结构（struct)），我们可以称之为程序容器（Application Container）(详情参见"清晰架构（Clean Architecture）的Go微服务: 程序容器（Application Container）") 。这样，我们就可以让业务逻辑保持不变，而使程序容器自我进化。大多数程序容器都用依赖注入来将对象(结构)注入到业务逻辑中，“Spring”就是一个很好的例子。但是，要使框架能够自我进化，关键是不能直接使用依赖注入作为这两部分之间的接口。相反，你必须使用一个非常简单的接口。当然，你依然可以使用依赖注入，但这只是在程序容器内部，因此只是程序容器的实现细节。

下面就是框架的结构图.

程序容器和业务逻辑之间的接口

程序容器和业务逻辑之间的接口应该非常简单。的功能就是让业务逻辑能获取具体对象(结构)。在清晰架构中，大多数情况下你只需要获取用例（Use Case）。

下面就是程序容器的接口:

type Container interface {
    // BuildUseCase creates concrete * for use case and it's included *.
    // For each call, it will create a new instance, which means it is not a singleton
    BuildUseCase(code string) (interface{}, error)

    // This should only be used by container and it's sub-package
    // Get instance by code from container.
    Get(code string) (interface{}, bool)

    // This should only be used by container and it's sub-package
    // Put value into container with code as the key.
    Put(code string, value interface{})

}