go语言依赖注入guan方,go语言依赖管理

GO语言商业案例（十六）：Curve-

Golang 的创建是为了实现最大的用户效率和编码效率。已经熟悉 Java 或 PHP 的程序员可以在几周内接受 Go 的培训（许多人最终会更喜欢它）。在本文中，Dewet Diener 探讨了 Golang 的优缺点，以及它的测试驱动开发 (TDD) 如何完美契合。

创新互联网站建设由有经验的网站设计师、开发人员和项目经理组成的专业建站团队，负责网站视觉设计、用户体验优化、交互设计和前端开发等方面的工作，以确保网站外观精美、成都网站设计、成都网站建设易于使用并且具有良好的响应性。

Golang 由 Google 开发和设计，于 2009 年作为一种综合性编程语言首次出现，旨在最大限度地提高编码效率。创建该语言的目的是修正其他已建立语言的缺陷。尽管 Golang（或简称为“Go”）是一门年轻的语言，但已经积累了大量的开发人员，因此我们想分享为什么在 Curve 我们喜欢 Golang，以及我们如何采用它来实现我们移动银行业务的目标到云端。

Go 是一种精致的编程语言：它支持“所见即所得”的原则，这意味着清晰易读的代码和更少的复杂抽象。该语言本身易于使用且易于训练。尽管如此，作为一个相对较新的生态系统，要找到对 Go 具有广泛预先知识的工程师可能会很棘手。

然而，与其他编程语言不同，Go 的创建是为了最大限度地提高用户效率。因此，具有 Java 或 PHP 背景的开发人员和工程师可以在几周内获得使用 Go 的技能和培训——根据我们的经验，他们中的许多人最终更喜欢它。

在 Curve，我们大力提倡测试驱动开发 (TDD)，Go 的框架与这种方法保持一致。通过简单地命名一个文件 foo_test.go 并在该文件中添加结构化测试函数，Go 将快速有效地运行您的单元测试。这一创新功能提高了生产力，因为它可以更加专注于测试驱动的开发和改进的同行评审机会。

Golang 具有出色的生产优化品质，例如内存占用小，这支持其在大型项目中作为构建块的能力，以及开箱即用的与其他架构的轻松交叉编译。由于 Go 代码被编译为单个静态二进制文件，因此它可以轻松进行容器化，并且通过扩展，将 Go 部署到任何高可用性环境（例如 Kubernetes）中几乎是微不足道的。

它提供了一种机制来保护工作负载，通过拥有非常纤薄的生产容器而没有任何无关的依赖项。这使得构建、部署和维护基于 Go 的资产更加直接和安全，并为希望建立或发展其微服务战略的公司提供了可靠的选择。

Go 是专门为满足我们快速发展的技术生态系统的需求而创建的。例如，Go 可以满足您构建 API 所需的一切，并将其作为其标准库的一部分。它使用简单，高性能的 http 服务器消除了团队设计新项目时经常发生的一些常见的 探索 和设计瘫痪问题——这对于一些其他流行语言（如 Java 和 Node.js）来说太常见了。

Golang 还通过其内置于语言本身的自动格式化程序巧妙地解决了代码格式化分歧。这完全消除了格式争议，进而提高了团队的生产力和注意力。

尽管我是 Go 的拥护者，但它显然也不是没有缺陷。一个争论不休的特性是 Go 没有显式接口，这是许多开发人员习惯的概念。虽然不是有害的，但它可以使选择最适合您的结构的接口成为一项任务。这是因为您不会像在其他流行的编程语言中那样编写 X 实现 Y，但您很快就会接受。

依赖管理也是另一个不属于 Google Golang 开发团队原始设计的功能。开源社区介入并创建了 Glide 和 Dep，最初的努力并没有完全解决问题。从 Go 1.11 开始，添加了对模块的支持，这似乎已成为官方的依赖管理工具。这些挑战并没有削弱 Go 作为一种高效编程语言的独创性，并且它继续为我们提供优于其他编程语言的显着优势。

Golang 吸引了全球敏锐的开发人员的注意，并且围绕它的兴奋继续增长。开源社区因有趣的项目而蓬勃发展；最著名的是 Docker 和 Kubernetes。

正是这种新鲜、有创意但又简单的包装吸引了我们去Go：它是一种令人兴奋的编码语言，可以帮助我们在 Curve 中快速开发以构建更好的产品。

「测试开发全栈化-Go」(1) Go语言基本了解

作为一个测试，作为一个测试开发， 全栈化+管理 是我们未来的发展方向。已经掌握了Java、Python、HTML的你，是不是也想了解下最近异常火爆的Go语言呢？来吧，让我们一起了解下。

Go 是一个开源的编程语言 ，它能让构造简单、可靠且高效的软件变得容易。

Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发，后来还加入了Ian Lance Taylor, Russ Cox等人，并最终于2009年11月开源，在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的，并且拥有一个活跃的社区。这三个人都是计算机界的大神，有的参与了C语言的编写，有的还是数学大神，有的还获得了计算机最高荣誉-图灵奖。

接下来说说 Go语言的特色 :

简洁、快速、安全

并行、有趣、开源

内存管理、数组安全、编译迅速

Go语言的用途 :

Go 语言被设计成一门应用于搭载 Web 服务器，存储集群或类似用途的巨型中央服务器的系统编程语言。

对于高性能分布式系统领域而言，Go 语言无疑比大多数其它语言有着更高的开发效率。它提供了海量并行的支持，这对于 游戏 服务端的开发而言是再好不过了。

Go语言的环境安装:

建议直接打开 官方地址因为墙的原因打不开

因为我用的是windows系统，这里主要讲下Windows系统上使用Go语言来编程。

Windows 下可以使用 .msi 后缀(在下载列表中可以找到该文件，如go1.17.2.windows-amd64.msi)的安装包来安装。

默认情况下 .msi 文件会安装在 c:Go 目录下。你可以将 c:Gobin 目录添加到 Path 环境变量中。添加后你需要重启命令窗口才能生效。个人建议还是安装到 Program Files文件夹中。

使用什么开发工具来对Go语言进行编写:

个人建议用VS code, 也可以用Sublime Text来编辑。如果你之前看了我讲的HTML语言的学习，肯定已经下载了VS code. 那么这时你需要在VS code中下载Go语言的扩展插件。

这里有一个巨大的坑，就是在下载Go的插件和依赖包时，会提示一些包没有。主要是因为下载的依赖包部分被墙了，只能想别的办法去下载。

建议参考网页:

解决vscode中golang插件安装失败方法

在学习go的过程中，使用的是vscode，但是一直提示安装相关插件失败，然后上网查方法，基本上是叫你建立golang.org目录什么的，结果全是错的，而且都是抄袭，很烦。无意之中看到一位博主分享的方法，他也是饱受上述的垃圾博文困扰，然后找到了解决方法，这里向他致敬，秉着让更多人看到正确解决方法的心，我写下正确的解决方法，希望对你有所帮助，也可以点开原博主链接参考：

Go有一个全球模块代理，设置代理再去安装golang的插件，就可以安装成功了。步骤有，首先Windows用户打开Powershell，一个蓝色的界面，注意不是cmd！不知道的直接打开window下面的搜索，然后输入powershell，搜索出来就可以了。

$env:GO111MODULE=“on”

$env:GOPROXY=“”

go env -w GOPROXY=

go env -w GOPRIVATE=*.corp.example.com

然后我们打开VsCode界面，下面会提示安装插件，我们选择Install ALL，就会安装成功

当你在运行Go语言程序时，提示所有的插件包都已经安装成功了时，就可以正常使用了，要不然一堆报错会让你非常心烦。

好了，今天先到这里，晚安、下班~

go依赖注入dig包使用-来自uber公司

原文链接：

github:

Dependency Injection is the idea that your components (usually structs in go) should receive their dependencies when being created. This runs counter to the associated anti-pattern of components building their own dependencies during initialization. Let’s look at an example.

Suppose you have a Server struct that requires a Config struct to implement its behavior. One way to do this would be for the Server to build its own Config during initialization.

This seems convenient. Our caller doesn’t have to be aware that our Server even needs access to Config . This is all hidden from the user of our function.

However, there are some disadvantages. First of all, if we want to change the way our Config is built, we’ll have to change all the places that call the building code. Suppose, for example, our buildMyConfigSomehow function now needs an argument. Every call site would need access to that argument and would need to pass it into the building function.

Also, it gets really tricky to mock the behavior of our Config . We’ll somehow have to reach inside of our New function to monkey with the creation of Config .

Here’s the DI way to do it:

Now the creation of our Server is decoupled from the creation of the Config . We can use whatever logic we want to create the Config and then pass the resulting data to our New function.

Furthermore, if Config is an interface, this gives us an easy route to mocking. We can pass anything we want into New as long as it implements our interface. This makes testing our Server with mock implementations of Config simple.

The main downside is that it’s a pain to have to manually create the Config before we can create the Server . We’ve created a dependency graph here – we must create our Config first because of Server depends on it. In real applications these dependency graphs can become very large and this leads to complicated logic for building all of the components your application needs to do its job.

This is where DI frameworks can help. A DI framework generally provides two pieces of functionality:

A DI framework generally builds a graph based on the “providers” you tell it about and determines how to build your objects. This is very hard to understand in the abstract, so let’s walk through a moderately-sized example.

We’re going to be reviewing the code for an HTTP server that delivers a JSON response when a client makes a GET request to /people . We’ll review the code piece by piece. For simplicity sake, it all lives in the same package ( main ). Please don’t do this in real Go applications. Full code for this example can be found here .

First, let’s look at our Person struct. It has no behavior save for some JSON tags.

A Person has an Id , Name and Age . That’s it.

Next let’s look at our Config . Similar to Person , it has no dependencies. Unlike Person , we will provide a constructor.

Enabled tells us if our application should return real data. DatabasePath tells us where our database lives (we’re using sqlite). Port tells us the port on which we’ll be running our server.

Here’s the function we’ll use to open our database connection. It relies on our Config and returns a *sql.DB .

Next we’ll look at our PersonRepository . This struct will be responsible for fetching people from our database and deserializing those database results into proper Person structs.

PersonRepository requires a database connection to be built. It exposes a single function called FindAll that uses our database connection to return a list of Person structs representing the data in our database.

To provide a layer between our HTTP server and the PersonRepository , we’ll create a PersonService .

Our PersonService relies on both the Config and the PersonRepository . It exposes a function called FindAll that conditionally calls the PersonRepository if the application is enabled.

Finally, we’ve got our Server . This is responsible for running an HTTP server and delegating the appropriate requests to our PersonService .

The Server is dependent on the PersonService and the Config .

Ok, we know all the components of our system. Now how the hell do we actually initialize them and start our system?

First, let’s write our main() function the old fashioned way.

First, we create our Config . Then, using the Config , we create our database connection. From there we can create our PersonRepository which allows us to create our PersonService . Finally, we can use this to create our Server and run it.

Phew, that was complicated. Worse, as our application becomes more complicated, our main will continue to grow in complexity. Every time we add a new dependency to any of our components, we’ll have to reflect that dependency with ordering and logic in the main function to build that component.

As you might have guessed, a Dependency Injection framework can help us solve this problem. Let’s examine how.

The term “container” is often used in DI frameworks to describe the thing into which you add “providers” and out of which you ask for fully-build objects. The dig library gives us the Provide function for adding providers and the Invoke function for retrieving fully-built objects out of the container.

First, we build a new container.

Now we can add new providers. To do so, we call the Provide function on the container. It takes a single argument: a function. This function can have any number of arguments (representing the dependencies of the component to be created) and one or two return values (representing the component that the function provides and optionally an error).

The above code says “I provide a Config type to the container. In order to build it, I don’t need anything else.” Now that we’ve shown the container how to build a Config type, we can use this to build other types.

This code says “I provide a *sql.DB type to the container. In order to build it, I need a Config . I may also optionally return an error.”

In both of these cases, we’re being more verbose than necessary. Because we already have NewConfig and ConnectDatabase functions defined, we can use them directly as providers for the container.

Now, we can ask the container to give us a fully-built component for any of the types we’ve provided. We do so using the Invoke function. The Invoke function takes a single argument – a function with any number of arguments. The arguments to the function are the types we’d like the container to build for us.

The container does some really smart stuff. Here’s what happens:

That’s a lot of work the container is doing for us. In fact, it’s doing even more. The container is smart enough to build one, and only one, instance of each type provided. That means we’ll never accidentally create a second database connection if we’re using it in multiple places (say multiple repositories).

Now that we know how the dig container works, let’s use it to build a better main.

The only thing we haven’t seen before here is the error return value from Invoke . If any provider used by Invoke returns an error, our call to Invoke will halt and that error will be returned.

Even though this example is small, it should be easy to see some of the benefits of this approach over our “standard” main. These benefits become even more obvious as our application grows larger.

One of the most important benefits is the decoupling of the creation of our components from the creation of their dependencies. Say, for example, that our PersonRepository now needs access to the Config . All we have to do is change our NewPersonRepository constructor to include the Config as an argument. Nothing else in our code changes.

Other large benefits are lack of global state, lack of calls to init (dependencies are created lazily when needed and only created once, obviating the need for error-prone init setup) and ease of testing for individual components. Imagine creating your container in your tests and asking for a fully-build object to test. Or, create an object with mock implementations of all dependencies. All of these are much easier with the DI approach.

I believe Dependency Injection helps build more robust and testable applications. This is especially true as these applications grow in size. Go is well suited to building large applications and has a great DI tool in dig . I believe the Go community should embrace DI and use it in far more applications.

golang反射框架Fx

Fx是一个golang版本的依赖注入框架，它使得golang通过可重用、可组合的模块化来构建golang应用程序变得非常容易，可直接在项目中添加以下内容即可体验Fx效果。

Fx是通过使用依赖注入的方式替换了全局通过手动方式来连接不同函数调用的复杂度，也不同于其他的依赖注入方式，Fx能够像普通golang函数去使用，而不需要通过使用struct标签或内嵌特定类型。这样使得Fx能够在很多go的包中很好的使用。

接下来会提供一些Fx的简单demo，并说明其中的一些定义。

1、一般步骤

大致的使用步骤就如下。下面会给出一些完整的demo

2、简单demo

将io.reader与具体实现类关联起来

输出：

3、使用struct参数

前面的使用方式一旦需要进行注入的类型过多，可以通过struct参数方式来解决

输出

如果通过Provide提供构造函数是生成相同类型会有什么问题?换句话也就是相同类型拥有多个值呢？

下面两种方式就是来解决这样的问题。

4、使用struct参数+Name标签

在Fx未使用Name或Group标签时不允许存在多个相同类型的构造函数，一旦存在会触发panic。

输出

上面通过Name标签即可完成在Fx容器注入相同类型

5、使用struct参数+Group标签

使用group标签同样也能完成上面的功能

输出

基本上Fx简单应用在上面的例子也做了简单讲解

1、Annotated(位于annotated.go文件) 主要用于采用annotated的方式,提供Provide注入类型

源码中Name和Group两个字段与前面提到的Name标签和Group标签是一样的，只能选其一使用

2、App(位于app.go文件) 提供注入对象具体的容器、LiftCycle、容器的启动及停止、类型变量及实现类注入和两者映射等操作

至于Provide和Populate的源码相对比较简单易懂在这里不在描述

具体源码

3、Extract（位于extract.go文件）

主要用于在application启动初始化过程通过依赖注入的方式将容器中的变量值来填充给定的struct，其中target必须是指向struct的指针，并且只能填充可导出的字段(golang只能通过反射修改可导出并且可寻址的字段)，Extract将被Populate代替。 具体源码

4、其他

诸如Populate是用来替换Extract的，而LiftCycle和inout.go涉及内容比较多后续会单独提供专属文件说明。

在Fx中提供的构造函数都是惰性调用，可以通过invocations在application启动来完成一些必要的初始化工作：fx.Invoke(function); 通过也可以按需自定义实现LiftCycle的Hook对应的OnStart和OnStop用来完成手动启动容器和关闭，来满足一些自己实际的业务需求。

Fx框架源码解析

主要包括app.go、lifecycle.go、annotated.go、populate.go、inout.go、shutdown.go、extract.go(可以忽略,了解populate.go)以及辅助的internal中的fxlog、fxreflect、lifecycle