请问大家公司的微服务有多少种？多了的话怎么运维？

[whileFalse]

昨天看到 https://www.v2ex.com/t/711163

里面有个老哥说有一千多个微服务，惊了，不知道是一千多个服务实例还是一千多种服务。

我们公司有差不多一百种微服务，大半在 k8s 上，小半直接部署在 Tomcat 里。上线靠 jenkins 。 因为有些服务有构建先后次序的问题，所以构建要依次执行很耗时间。因为希望特定时间上线（比如中午 12 点 /夜里 12 点），所以要提前构建，到点再部署。这样每个服务有构建 /部署两个 Job，再加上顺序问题，每次上线涉及的服务一多那是鸡飞狗跳。

我搞了一个自动构建+模板渲染 yaml 的工具，算是极大降低了 k8s 服务的上线难度，预先写好要上线的服务列表，上线时一键执行。解决了两个问题：

1. 极大的降低了上线时的心智消耗，几乎不给出错的可能性
2. 通过模板渲染显著减少了不同服务的 yaml 差异。 虽然工具很好用，但我也有个疑惑：这种问题应该很多公司都会遇到，其他公司是怎么做的呢？总不会都是自己实现工具吧。

但是比较流行的 CICD 工具好像也不太合用。用中文搜了一下，一些国内的 K8s 管理方案主要是可视化。可视化感觉还是给新上手 k8s 的公司用的，跟 Jenkins 没本质区别。 另外有公司用推代码自动构建+手动部署的方式。这也不太适合我司：

1. 我司有 N 个测试环境，但没有每个环境对应的独立分支
2. 代码推送成功后不一定能构建成功（不同的服务会有构建先后次序的问题）
3. 部署和构建是分开的，推代码之后不一定能立即部署

构建（.jar/.war/DockerImage ）有先后顺序依赖。比如项目 B 依赖项目 A 的 SNAPSHOT，那么 A 必须先构建并将自身的 SNAPSHOT 安装到构建机器的本地仓库，然后 B 再构建才能拿到正确的 SNAPSHOT 版本。

部署服务没有顺序问题。

[singerll]

大公司肯定不是自己实现工具啊，都是一个团队在实现工具。

[whileFalse]

@singerll 我意思是有没有现成的工具？如果有现成的自己不知道还傻呵呵写就挺井底之蛙的。

[whileFalse]

@singerll 再说我就是 DevOps 职位，虽然不算“一个团队”，但确实是该写工具的岗位。

[GopherDaily]

服务注册、发现，健康检查、流控之类的功能不是强制的，内部调用还是走域名，那么只要你写的代码能跑就行。

另外一种是公司层面针对几种特定的应用类型（ web/consumer ）提供几种特定语言的支持，业务方在框架内写业务逻辑，框架负责和上面那些东西打教导。

单个应用类型下有多少实现不同业务逻辑的应用，这个数量一点都不关键

[cassyfar]

Spinnaker

[sampeng]

你最要解决的是，解决依次构建问题。需要依次部署在微服务就是个架构设计有问题的最明显特征。因为你无论如何都有两个版本同时存在的状态。所以为什么要依次部署呢…这应该是可以通过部署流程优化的。

[whileFalse]

@GopherDaily #4 微服务的部分我们用的 Spring Cloud 。

数量很重要。一次上线包含 3 个和一次上线包含 30 个服务是不同的概念。10 个以内的服务手动点点没啥问题，但手动点一大批就很烦。

[sampeng]

我司跟你情况一样。加起来上百个微服务。我也是 devops 。所以我不解决问题，我解决提出问题的人。服务不适合我自动化构建就改到合适为止。现在把上线都直接交给研发了…反正构建速度 ok，部署不出错，微服务完全没状态。有应急的情况有 hpa 自动伸缩，再大点的流量高峰是可以预知的。提前把 hpa 改大点完事…

[whileFalse]

@sampeng #6 需要依次构建，不需要依次部署。
构建的时候需要向本地安装一些 snapshot 的包，后续构建要用到这些包，所以需要按顺序。

[ElegantOfKing]

1.有部署平台，发布的时候运维点点点就行；
2.运维人手多；
3.有项目回滚平台，出现问题运维点点点；
4.有完整的预警平台，出现问题会通过邮件、短信和公司自研的通讯应用推送信息；
5.经常机房灾备演练。

[ElegantOfKing]

项目构建，还是用的公司自研的构建平台......可以选择同时构建和依次构建

[yamasa]

有点不太理解，‘我搞了一个自动构建+模板渲染 yaml 的工具‘，这是自己实现了一套类 Helm 吗？这功能跟 helm 太像了。

我们这儿是 gitlab cicd + helm + k8s, sde team 自己负责发布和部署，或者 sde team 开发一键式的 ui 供 devops 做部署，让 devops 尽量降低部署的心智负担。

生产上线之后，devops 需要关注各类 online alerts，sde team 预先提供 action table，如果还不行就提交给 sde team 自己解决。

[yamasa]

所谓依赖性部署，也很奇怪啊。合理的划分微服务之后，每个 squad 应该自行控制发布周期，一般情况不应该和其他微服务有耦合。每个微服务都应该保证 rolling update，traffic 不能断掉，且尽量做到向后兼容。经常都要一起，且依赖性部署的多个微服务，本身划分就有问题吧？

[xiaket]

我们的做法是各个服务的开发负责上线, 自己跑 pipeline 去, DevOps 或者说 SRE 负责审核 pipeline 的改动, 但是不在负责具体上线.

当然我们用的是 Buildkite, 不是我完全不想回头去用的 Jenkins. 两个月推掉了一个 offer, 一个小原因就是他们还是用 Jenkins

[sampeng]

@whileFalse 依次构建也一样啊。尽可能的并行执行…提高这个速度。部署时间就上来了…不过话说回来。总觉得这一步怪怪的…

[sampeng]

@xiaket 我们也一直 jenkins 啊。稳定才是王道…也没啥做不到的功能。你说的对。devops 做不到研发自己上线，这个流程就是没做好

[whileFalse]

@sampeng #15 构建总用时不是问题。讨厌的地方在于点第一个构建任务之后要等着……等它完事儿再点下一个。到了上线的点儿再一个个的点部署任务，部署任务倒是不用依次执行，可以并行。

@yamasa #12 看了一下 Helm，在模板渲染层面和我的工具挺像的。不过它似乎不包含构建和镜像管理功能？那该如何构建并引用正确的镜像呢？另外有工具能做到在测试和生产环境共享镜像吗？

[whileFalse]

@xiaket #14 Pipeline 挺好的！我觉得我们应该引入这个玩意儿。我们现在缺自动化测试的功能，流水线能提供；还缺比较优雅的手动批准。
我现在的做法是，运行一次“构建并预览更改”构建镜像并检查变更；没问题的话再运行一次“构建并部署”。第二次会自动跳过已经构建的镜像，不过还是会浪费一点时间，并且不够酷。

[liwl]

我们是 Pipeline build 一次 构建镜像一次 推送一次

[xiaket]

@whileFalse #17 为啥不在 Jenkinsfile 里面写逻辑直接 trigger 下一个任务的运行? 这样等着不是很浪费时间吗?

[xiaket]

@sampeng 嗯, 国内没有用这种付费服务的习惯, Jenkins 在开源实现里相对算好用的了. 但是实际上国外 CICD 的市场很大, 产品也不少, 都值得看看

[whileFalse]

@xiaket #20 那套玩意儿不是我做的，我来了就有了。另外我不是很了解 jenkins 。
请问如果每次要构建的目标不一样，Jenkinsfile 能很好的处理吗？

比如：
有 a-z 共 26 个服务。本次要上线的是 asdfgh 这几个服务，其中 a 要先于 s 构建，d 要先于 f 构建，其他的可以乱序或并行构建。全部构建完之后一起部署。这种需求 Jenkins 能搞定吗

[weimao]

用 helm 管理 k8s 上的所有配置文件
持续集成：bitbucket+drone——git tag 触发 docker build
持续部署：drone 配置 pipeline 实现 docker build 成功后触发 helm 配置更新、k8s 部署

[inhzus]

aone tce 一般都有一套完整的平台管理的（虽然用起来都挺屎

[lidashuang]

cd 试试 spinnaker ？

[oneisall8955]

pipeline，线上版本和 qa 镜像版本一致，没有上线部署时间长问题啊，最多上 qa 时候，测试等久一点

[firefox12]

看这个 https://www.cnblogs.com/89757m/p/13721854.html