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

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

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

这时一个能自我进化的框架就展现出优势。我们可以在项目开始时使用这个轻量级框架，并只在确实需要时才将其进化为重量级框架， 在这个过程中我们不需要重写整个项目或更改任何业务逻辑代码，当然你需要对创建结构（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 types for use case and it's included types.
	// 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{
   })

}

如何让程序容器进化

我定义了三种模式的程序容器，从最简单到最复杂，你可以直接使用。你也可以定义新的程序容器模式，只要它遵循上面的接口即可。你可以随时将程序容器替换为其他模式，而无需更改业务逻辑代码。

初级模式

这是最简单的模式，它不涉及任何设计模式。它的最大优点是简单，易学，易用。绝大多数的项目都可以从此模式开始。使用这种模式可以在一天之内创建整个项目。如果项目很简单，在一小时内完成都是有可能的。如果你不再需要这个项目，就可以一点也不可惜地丢弃它。缺点是它提供的功能非常简单，所有配置信息都是以硬编码的形式写在程序中，既不灵活也不强大。最适合POC（概念验证）类型的项目。具体实例可查看 “订单服务” 。这是一个事件驱动的微服务项目，旨在提供订单服务。

以下是初级模式的结构图，框内是程序容器：

增强模式

这种模式类似于初级模式，主要改进是增加了配置参数管理。在这种模式下，配置参数不再是硬编码在代码中的，它们是在结构（struts）中定义的。你也可以对它们进行校验。更改程序配置要容易得多，你可以在单个文件里看到项目的所有