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

2020-09-29 09:16:51 +08:00
 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. 部署和构建是分开的，推代码之后不一定能立即部署
4050 次点击
所在节点    问与答
27 条回复
singerll
2020-09-29 09:26:57 +08:00
大公司肯定不是自己实现工具啊，都是一个团队在实现工具。
whileFalse
2020-09-29 09:28:19 +08:00
@singerll 我意思是有没有现成的工具？如果有现成的自己不知道还傻呵呵写就挺井底之蛙的。
whileFalse
2020-09-29 09:29:47 +08:00
@singerll 再说我就是 DevOps 职位，虽然不算“一个团队”，但确实是该写工具的岗位。
GopherDaily
2020-09-29 09:30:40 +08:00
服务注册、发现，健康检查、流控之类的功能不是强制的，内部调用还是走域名，那么只要你写的代码能跑就行。

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

单个应用类型下有多少实现不同业务逻辑的应用，这个数量一点都不关键
cassyfar
2020-09-29 09:50:17 +08:00
Spinnaker
sampeng
2020-09-29 10:42:36 +08:00
你最要解决的是，解决依次构建问题。需要依次部署在微服务就是个架构设计有问题的最明显特征。因为你无论如何都有两个版本同时存在的状态。所以为什么要依次部署呢…这应该是可以通过部署流程优化的。
whileFalse
2020-09-29 10:44:46 +08:00
@GopherDaily #4 微服务的部分我们用的 Spring Cloud 。

数量很重要。一次上线包含 3 个和一次上线包含 30 个服务是不同的概念。10 个以内的服务手动点点没啥问题，但手动点一大批就很烦。
sampeng
2020-09-29 10:45:56 +08:00
我司跟你情况一样。加起来上百个微服务。我也是 devops 。所以我不解决问题，我解决提出问题的人。服务不适合我自动化构建就改到合适为止。现在把上线都直接交给研发了…反正构建速度 ok，部署不出错，微服务完全没状态。有应急的情况有 hpa 自动伸缩，再大点的流量高峰是可以预知的。提前把 hpa 改大点完事…
whileFalse
2020-09-29 10:47:06 +08:00
@sampeng #6 需要依次构建，不需要依次部署。
构建的时候需要向本地安装一些 snapshot 的包，后续构建要用到这些包，所以需要按顺序。
ElegantOfKing
2020-09-29 11:19:12 +08:00
1.有部署平台，发布的时候运维点点点就行；
2.运维人手多；
3.有项目回滚平台，出现问题运维点点点；
4.有完整的预警平台，出现问题会通过邮件、短信和公司自研的通讯应用推送信息；
5.经常机房灾备演练。
ElegantOfKing
2020-09-29 11:21:01 +08:00
项目构建，还是用的公司自研的构建平台......可以选择同时构建和依次构建
yamasa
2020-09-29 11:30:04 +08:00
有点不太理解，‘我搞了一个自动构建+模板渲染 yaml 的工具‘，这是自己实现了一套类 Helm 吗？这功能跟 helm 太像了。

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

生产上线之后，devops 需要关注各类 online alerts，sde team 预先提供 action table，如果还不行就提交给 sde team 自己解决。
yamasa
2020-09-29 11:32:56 +08:00
所谓依赖性部署，也很奇怪啊。合理的划分微服务之后，每个 squad 应该自行控制发布周期，一般情况不应该和其他微服务有耦合。每个微服务都应该保证 rolling update，traffic 不能断掉，且尽量做到向后兼容。经常都要一起，且依赖性部署的多个微服务，本身划分就有问题吧？
xiaket
2020-09-29 11:46:11 +08:00
我们的做法是各个服务的开发负责上线, 自己跑 pipeline 去, DevOps 或者说 SRE 负责审核 pipeline 的改动, 但是不在负责具体上线.

当然我们用的是 Buildkite, 不是我完全不想回头去用的 Jenkins. 两个月推掉了一个 offer, 一个小原因就是他们还是用 Jenkins
sampeng
2020-09-29 12:49:20 +08:00
@whileFalse 依次构建也一样啊。尽可能的并行执行…提高这个速度。部署时间就上来了…不过话说回来。总觉得这一步怪怪的…
sampeng
2020-09-29 12:50:56 +08:00
@xiaket 我们也一直 jenkins 啊。稳定才是王道…也没啥做不到的功能。你说的对。devops 做不到研发自己上线，这个流程就是没做好
whileFalse
2020-09-29 13:56:47 +08:00
@sampeng #15 构建总用时不是问题。讨厌的地方在于点第一个构建任务之后要等着……等它完事儿再点下一个。到了上线的点儿再一个个的点部署任务，部署任务倒是不用依次执行，可以并行。

@yamasa #12 看了一下 Helm，在模板渲染层面和我的工具挺像的。不过它似乎不包含构建和镜像管理功能？那该如何构建并引用正确的镜像呢？另外有工具能做到在测试和生产环境共享镜像吗？
whileFalse
2020-09-29 14:07:48 +08:00
@xiaket #14 Pipeline 挺好的！我觉得我们应该引入这个玩意儿。我们现在缺自动化测试的功能，流水线能提供；还缺比较优雅的手动批准。
我现在的做法是，运行一次“构建并预览更改”构建镜像并检查变更；没问题的话再运行一次“构建并部署”。第二次会自动跳过已经构建的镜像，不过还是会浪费一点时间，并且不够酷。
liwl
2020-09-29 14:30:07 +08:00
我们是 Pipeline build 一次 构建镜像一次 推送一次
xiaket
2020-09-29 17:05:55 +08:00
@whileFalse #17 为啥不在 Jenkinsfile 里面写逻辑直接 trigger 下一个任务的运行? 这样等着不是很浪费时间吗?

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/711442

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX