V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
whileFalse
V2EX  ›  问与答

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

  •  1
     
  •   whileFalse · 2020-09-29 09:16:51 +08:00 · 4056 次点击
    这是一个创建于 1551 天前的主题,其中的信息可能已经有所发展或是发生改变。

    昨天看到 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. 部署和构建是分开的,推代码之后不一定能立即部署
    第 1 条附言  ·  2020-09-29 11:42:05 +08:00
    构建(.jar/.war/DockerImage )有先后顺序依赖。比如项目 B 依赖项目 A 的 SNAPSHOT,那么 A 必须先构建并将自身的 SNAPSHOT 安装到构建机器的本地仓库,然后 B 再构建才能拿到正确的 SNAPSHOT 版本。

    部署服务没有顺序问题。
    27 条回复    2020-09-29 23:09:52 +08:00
    singerll
        1
    singerll  
       2020-09-29 09:26:57 +08:00 via Android
    大公司肯定不是自己实现工具啊,都是一个团队在实现工具。
    whileFalse
        2
    whileFalse  
    OP
       2020-09-29 09:28:19 +08:00
    @singerll 我意思是有没有现成的工具?如果有现成的自己不知道还傻呵呵写就挺井底之蛙的。
    whileFalse
        3
    whileFalse  
    OP
       2020-09-29 09:29:47 +08:00
    @singerll 再说我就是 DevOps 职位,虽然不算“一个团队”,但确实是该写工具的岗位。
    GopherDaily
        4
    GopherDaily  
       2020-09-29 09:30:40 +08:00
    服务注册、发现,健康检查、流控之类的功能不是强制的,内部调用还是走域名,那么只要你写的代码能跑就行。

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

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

    数量很重要。一次上线包含 3 个和一次上线包含 30 个服务是不同的概念。10 个以内的服务手动点点没啥问题,但手动点一大批就很烦。
    sampeng
        8
    sampeng  
       2020-09-29 10:45:56 +08:00 via iPhone   ❤️ 1
    我司跟你情况一样。加起来上百个微服务。我也是 devops 。所以我不解决问题,我解决提出问题的人。服务不适合我自动化构建就改到合适为止。现在把上线都直接交给研发了…反正构建速度 ok,部署不出错,微服务完全没状态。有应急的情况有 hpa 自动伸缩,再大点的流量高峰是可以预知的。提前把 hpa 改大点完事…
    whileFalse
        9
    whileFalse  
    OP
       2020-09-29 10:47:06 +08:00
    @sampeng #6 需要依次构建,不需要依次部署。
    构建的时候需要向本地安装一些 snapshot 的包,后续构建要用到这些包,所以需要按顺序。
    ElegantOfKing
        10
    ElegantOfKing  
       2020-09-29 11:19:12 +08:00   ❤️ 1
    1.有部署平台,发布的时候运维点点点就行;
    2.运维人手多;
    3.有项目回滚平台,出现问题运维点点点;
    4.有完整的预警平台,出现问题会通过邮件、短信和公司自研的通讯应用推送信息;
    5.经常机房灾备演练。
    ElegantOfKing
        11
    ElegantOfKing  
       2020-09-29 11:21:01 +08:00
    项目构建,还是用的公司自研的构建平台......可以选择同时构建和依次构建
    yamasa
        12
    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
        13
    yamasa  
       2020-09-29 11:32:56 +08:00
    所谓依赖性部署,也很奇怪啊。合理的划分微服务之后,每个 squad 应该自行控制发布周期,一般情况不应该和其他微服务有耦合。每个微服务都应该保证 rolling update,traffic 不能断掉,且尽量做到向后兼容。经常都要一起,且依赖性部署的多个微服务,本身划分就有问题吧?
    xiaket
        14
    xiaket  
       2020-09-29 11:46:11 +08:00
    我们的做法是各个服务的开发负责上线, 自己跑 pipeline 去, DevOps 或者说 SRE 负责审核 pipeline 的改动, 但是不在负责具体上线.

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

    @yamasa #12 看了一下 Helm,在模板渲染层面和我的工具挺像的。不过它似乎不包含构建和镜像管理功能?那该如何构建并引用正确的镜像呢?另外有工具能做到在测试和生产环境共享镜像吗?
    whileFalse
        18
    whileFalse  
    OP
       2020-09-29 14:07:48 +08:00
    @xiaket #14 Pipeline 挺好的!我觉得我们应该引入这个玩意儿。我们现在缺自动化测试的功能,流水线能提供;还缺比较优雅的手动批准。
    我现在的做法是,运行一次“构建并预览更改”构建镜像并检查变更;没问题的话再运行一次“构建并部署”。第二次会自动跳过已经构建的镜像,不过还是会浪费一点时间,并且不够酷。
    liwl
        19
    liwl  
       2020-09-29 14:30:07 +08:00
    我们是 Pipeline build 一次 构建镜像一次 推送一次
    xiaket
        20
    xiaket  
       2020-09-29 17:05:55 +08:00
    @whileFalse #17 为啥不在 Jenkinsfile 里面写逻辑直接 trigger 下一个任务的运行? 这样等着不是很浪费时间吗?
    xiaket
        21
    xiaket  
       2020-09-29 17:15:40 +08:00
    @sampeng 嗯, 国内没有用这种付费服务的习惯, Jenkins 在开源实现里相对算好用的了. 但是实际上国外 CICD 的市场很大, 产品也不少, 都值得看看
    whileFalse
        22
    whileFalse  
    OP
       2020-09-29 17:16:28 +08:00
    @xiaket #20 那套玩意儿不是我做的,我来了就有了。另外我不是很了解 jenkins 。
    请问如果每次要构建的目标不一样,Jenkinsfile 能很好的处理吗?

    比如:
    有 a-z 共 26 个服务。本次要上线的是 asdfgh 这几个服务,其中 a 要先于 s 构建,d 要先于 f 构建,其他的可以乱序或并行构建。全部构建完之后一起部署。这种需求 Jenkins 能搞定吗
    weimao
        23
    weimao  
       2020-09-29 20:13:32 +08:00
    用 helm 管理 k8s 上的所有配置文件
    持续集成:bitbucket+drone——git tag 触发 docker build
    持续部署:drone 配置 pipeline 实现 docker build 成功后触发 helm 配置更新、k8s 部署
    inhzus
        24
    inhzus  
       2020-09-29 21:01:57 +08:00 via Android
    aone tce 一般都有一套完整的平台管理的(虽然用起来都挺屎
    lidashuang
        25
    lidashuang  
       2020-09-29 21:05:30 +08:00
    cd 试试 spinnaker ?
    oneisall8955
        26
    oneisall8955  
       2020-09-29 21:20:53 +08:00 via Android
    pipeline,线上版本和 qa 镜像版本一致,没有上线部署时间长问题啊,最多上 qa 时候,测试等久一点
    firefox12
        27
    firefox12  
       2020-09-29 23:09:52 +08:00
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1018 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 19:37 · PVG 03:37 · LAX 11:37 · JFK 14:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.