“What I cannot create, I do not understand. – Richard Feynman”
微服务部署是一个难题，包括了一系列开发中的实际问题。例如是否将所有微服务代码放在一个git仓库还是分git仓库，是否需要公共代码（这里的公共代码指的是与业务逻辑无关在任何项目中都可以即开即用的脚手架代码），部署方式是否使用jenkins自动化部署还是自己写个脚本，部署方式又有可能会跟是否分git仓库相关。所以这里可以扯一大堆，我只讲一些我认为可行的操作。
使用单仓库编译
目前我比较同意一种方式部署方式，并不排除后面会改用更加高效的方式。方式是这样的，使用git管理整个项目，包括所有微服务。如何编译部署？在之前的单体架构中，一般流程是这样的，用户提交代码到github，触发jenkins hook，jenkins进行构建操作。但是现在代码都放在一个仓库中，我们需要build不同服务的代码，因此不能在github那层做文章，比方说可以在commit message指定要build的服务？我选择的方法是自己触发不同的jenkins job，并在push之后触发jenkins构建。push服务指定分支，指定服务即可。这里有一个问题就是如何对修改的服务触发构建，比较多的实践是根据脚本判断改动，因为不同的服务是在不同的文件夹的，所以可以通过判断文件改动来区分服务改动
|
|
部署在kubernetes
服务已经build出来，可以直接把bin文件丢到目标服务器，也可以将bin文件编入docker image，然后把image发布到docker register，在远程服务器上执行upgrade svr操作。从整个流程可以划分为编码、编译打包、部署这么几个步骤。
kubernetes是服务编排工具，现在大部分是拿kubernetes编排docker容器。kubernetes的优势在于负载均衡、横向扩容、资源分配、服务自动发现，减少了运维人员的心智负担。针对开发人员来说，kubernetes的部署配置也是需要去了解的，kubernetes需要根据配置拉取不同版本的docker image去运行，一般的做法是使用代码的commit版本作为image版本，如果把config文件和代码放在同一个git仓库，则会出现鸡生蛋、蛋生鸡的问题，因此最好的办法是将config放到另外的git仓库，在jenkins 部署中更新config，并将最新的config替换服务器端的config，如此便可走通整个kubernetes部署。
http://siddontang.com/
http://www.cs.cmu.edu/~srini/15-440/ Distributed Systems
http://15721.courses.cs.cmu.edu/spring2016/ Database Systems
