当咱们使用微服务架构以后,紧接而来的问题即是服务之间的程序集引用问题,可能没接触过的同窗不太理解这句话,都已经微服务化了为何还要互相引用程序集,固然能够不引用。可是咱们会有这样一种状况,咱们的每一个接口都会有请求参数和返回结果,规范来讲咱们须要为每一个接口分别建立一个请求类(Request)和返回类(Response)。当其余服务或者程序须要调用这个接口传递参数和获得返回结果的时候,最方便的方式就是直接使用服务的程序集,而不是两边同时建立Request和RResponse。同时咱们还须要对程序集进行版本控制,并且高本版须要兼容低版本。经过NuGet来进行程序集的使用和版本控制是一件百利而无一害的事,我如今所在的公司即是使用这种方式。docker
这里说一下我被dll版本坑哭的经历,同时也为如今处处拷贝dll的同窗作个提示。我如今的公司架构是从三层改造到微服务的,因此在Web端依然存在着部分三层代码,不一样项目之间进行的程序集使用是经过拷贝dll的形式(这里有两个三层项目,尚未彻底服务化),A项目中使用了某个服务的程序集,B项目中也使用了该服务的程序集,此时把A项目类库的dll拷贝到B项目中,若是两个相同服务的程序集版本不一致,恭喜你,等着报错吧兄弟(想到这里我就要哭了,第一次不知道被坑惨了,补了一夜的数据) !!固然你可能会说难道你拷贝完都不测试的吗,咱们本身的开发组如今有40多个服务,同时还引用了其它组的服务,当时那个项目里有十七八个服务的程序集,一堆人开发,一方面我当时不知道这个坑,另外一方面我也没去看代码提交记录谁升级了某个服务的版本,结果发布还没2分钟,大量日志报警袭来:xxx程序集版本未找到!!唉,当晚补数据到凌晨2点,因此,对于程序集的使用,进行规范化的管理是很是有必要的,更重要的是不要拷贝dll!!!服务器
咱们此次使用Docker搭建一个本身的NuGet服务器(由于Docker实在太简单了,我已经懒到无可救药了):架构
docker run -d -p 8090:80 -v $PWD/nuget/db:/var/www/db -v $PWD/nuget/packages:/var/www/packagefiles -e NUGET_API_KEY=ee28314c-f7fe-2550-bd77-e09eda3d0119 sunside/simple-nuget-serveride
这里环境变量NUGET_API_KEY要记住后面的命令须要使用
成功后以下图所示:微服务
使用cmd命令到项目文件夹下,执行 dotnet pack 命令:测试
下载Nuget.exe (下载地址https://dist.nuget.org/win-x86-commandline/v4.7.0/nuget.exe)
将Nuget.exe 放置 C:\Program Files\dotnet目录下(通常安装了netcoreSDK 必定有这个目录)spa
cmd到项目Debug文件夹下,会看到生成的项目包,执行以下命令:3d
nuget push -Source http://47.99.92.76:8090/ -ApiKey ee28314c-f7fe-2550-bd77-e09eda3d0119 MI.Untity.1.0.0.nupkg (这里的ApiKey则是第一步的环境变量详细参数查看https://docs.microsoft.com/zh-cn/nuget/tools/cli-ref-push)
项目里配置包地址,而后就可使用了!版本控制