V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
darknoll
V2EX  ›  程序员

没有高并发的场景,整微服务、服务发现、集群啥的,是不是有点步子迈太大了?

  •  
  •   darknoll · 2021-02-10 17:11:19 +08:00 via Android · 6207 次点击
    这是一个创建于 1365 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我司做制造业相关的软件,一般都是部署在公司内网,原先都是桌面程序,socket 通信,现在大势所趋需要转型到 web,领导提出的架构:要用微服务、服务发现、集群这些做,是不是有点杀鸡用牛刀了?
    47 条回复    2021-02-15 17:18:19 +08:00
    niubee1
        1
    niubee1  
       2021-02-10 17:17:12 +08:00
    你问问领导有多少预算要上多少台服务器先
    darknoll
        2
    darknoll  
    OP
       2021-02-10 17:17:57 +08:00 via Android
    @niubee1 不超过 4 台,都是内网用的
    anguiao
        3
    anguiao  
       2021-02-10 17:23:08 +08:00 via Android
    这不挺好吗,带薪学习它不香吗?
    niubee1
        4
    niubee1  
       2021-02-10 17:25:52 +08:00
    同意 3 楼,老板都不介意给你机会学习了,就别纠结了
    lululau
        5
    lululau  
       2021-02-10 17:26:13 +08:00 via iPhone
    同意 3 楼,公司出钱让你学习不是好事吗
    raaaaaar
        6
    raaaaaar  
       2021-02-10 17:43:40 +08:00
    如果你是老板,是管理层,你再思考这些问题,如果你就是个打工仔,那你应该高兴。
    luzhh
        7
    luzhh  
       2021-02-10 17:56:02 +08:00
    好事,同意三楼的说法,不要错过这波机会,公司提供给你试错机会了,好好干,干好了回报很大。
    iamppz
        8
    iamppz  
       2021-02-10 17:58:11 +08:00
    投标的时候这些都是加分项,另外微服务化也有利于以后的平台化转型呀
    mooyo
        9
    mooyo  
       2021-02-10 18:46:46 +08:00 via iPhone
    挺好的啊 做微服务又不麻烦 提前拆分还方便后续的维护升级
    dnsaq
        10
    dnsaq  
       2021-02-10 21:22:49 +08:00
    小公司人人都说要比肩 BAT,预算和人手凑桌麻将都凑不齐。
    liuzhaowei55
        11
    liuzhaowei55  
       2021-02-10 21:43:15 +08:00 via iPhone   ❤️ 12
    我来唱个反调吧,如果业务较小且单一,特别是人手还不足,不要把线上服务搞的这么复杂,带薪学习是不错,线上服务容错性低,到头来业务跟不上,这些东西上了也是白上,你根本体会不到它们带来的优势,反而是徒增苦恼。
    cnleon
        12
    cnleon  
       2021-02-10 21:56:04 +08:00
    面向简历编程
    idoggy
        13
    idoggy  
       2021-02-10 23:07:54 +08:00 via Android
    搭个 nginx 玩玩算了,4 台服务器想干啥呀
    vandort
        14
    vandort  
       2021-02-10 23:45:09 +08:00   ❤️ 11
    同意 11 楼的说法。你可以先问自己三个问题:
    1 、团队技术积累够不够?
    2 、公司基础设施建设有没有到位?
    3 、出了问题谁负责定位、排障、解决?

    除非你打算半年内跑路,不然研发团队的可持续发展跟个人的技术成长同样重要。团队技术积累不够,基础设施建设不足,都是很要命的事情。比如你做服务拆分,拆成了很多个微服务,但是没有 ELK (或者其他类似东西),没有配置管理,没有链路跟踪,测试也是手动黑盒点点点,有了问题你要怎么去定位呢?开一屏的终端 tail -f 吗?如果客户要求配置额外的安全策略,要逐个配置文件的去改吗?

    考虑另外一个情况,如果为了去贴“集群”的概念,不小心用了 k8s (或者其他类似东西),碰见大坑了要怎么办?外面招不来懂云计算的人,内部的团队又爬不出去。以你们团队领导的风格,是会 997 爆肝刷苦劳、扣发奖金解散团队,还是会重金聘请顾问解决问题,然后公正地复盘问题,亡羊补牢呢?

    另外,其他的研发同事的能力足以上手这些新的技术吗?输出的文档可以帮助阅读的人理解系统吗(真的有文档吗)?测试团队能不能理清服务拆分之后的整体架构?交付团队能不能消化新架构带来的学习成本呢?

    如果领导不参与具体的研发工作,我建议不妨先用自己的能力范围之内的技术完成需求(然后包装一下对外汇报),再一点一点的在自己的舒适区边缘向外试探。进可向先进的、有前景的技术方向演进,退可迅速回滚到你能掌控的版本,降低风险不可控的概率。这样你可以跟公司一起成长,即使想另谋高就,也会更加从容一些。
    js8510
        15
    js8510  
       2021-02-11 00:37:24 +08:00
    你有多少开发,办多少事。。如果就一个团队,开发多个“微”服务,开发着开发者你就会发现成一个服务了。

    服务架构是人事架构的镜像。
    passerbytiny
        16
    passerbytiny  
       2021-02-11 00:38:11 +08:00 via Android
    服务中心+配置中心+网关+两个服务,加起来内存占用不超过 3G (其中 1.5G 还是额外预留的)。实际上微服务集群比单节点并没需要更多的硬件资源。
    securityCoding
        17
    securityCoding  
       2021-02-11 01:06:43 +08:00
    说明你们的领导务虚不务实,尤其是你提到了私有部署到时候会把开发给坑死
    securityCoding
        18
    securityCoding  
       2021-02-11 01:08:20 +08:00
    @mooyo 不是每个公司都有强力的基础团队做支撑的.
    mooyo
        19
    mooyo  
       2021-02-11 01:23:43 +08:00 via iPhone
    @securityCoding 这点很同意 得有一个完整的运维团队 or 舍得氪金上公有云才能玩转这一套
    akira
        20
    akira  
       2021-02-11 03:11:13 +08:00
    是。
    但是这种机会难得呀。有人给发工资 让你学习,偷着了呗
    zengming00
        21
    zengming00  
       2021-02-11 09:02:13 +08:00
    公司会为此付出惨痛的教训
    dream4ever
        22
    dream4ever  
       2021-02-11 10:06:02 +08:00
    11 楼和 14 楼一看就是过来人,建议多听听这两位的意见。
    bzshow1
        23
    bzshow1  
       2021-02-11 10:27:49 +08:00 via Android
    直接用 bilibili 的架构
    darknoll
        24
    darknoll  
    OP
       2021-02-11 10:55:32 +08:00
    @vandort 其他的研发同事的能力——只会 socket,HTTP 还没怎么用过,web 从没做过
    kkbblzq
        25
    kkbblzq  
       2021-02-11 11:33:26 +08:00
    看你们公司有没有比较有经验的 devops 团队了。。。这玩意不只对研发有需求,对运维也有需求的,就算上云商也少不了这些的。。
    scofieldpeng
        26
    scofieldpeng  
       2021-02-11 12:17:14 +08:00   ❤️ 2
    楼上说什么带薪学习的省省吧,企业要求的是稳定,和 11 楼,14 楼说的,真要学习,自己云上买个主机玩玩,或者家里搞个破烂服务器都能玩,老实说,量没上去,业务没上去,别搞那些虚的,什么微服务,其他我就不说了,同样的东西,你微服务要多少时间?更不要说什么运维之类的成本了,别抱什么侥幸心理不会挂之类的,线上到时候真跪了你难道要给客户说我们上了一个很牛逼的东西,但是这东西我们还是在学习期?
    wangxiaoaer
        27
    wangxiaoaer  
       2021-02-11 12:40:51 +08:00 via iPhone
    微服务可以考虑,但别像有些教程那样拆的太细。

    服务发现啥的久别扯淡了,就你那几个服务一眼就看完,人工发现就 OK 了。

    集群无所谓,看情况。
    young1lin
        28
    young1lin  
       2021-02-11 13:12:21 +08:00
    要我,我偷着乐了,我可能年后去一个二线大厂打工还用不到微服务呢。

    带薪学习,先干他个半年。简历上重构原有项目至微服务架构。

    不过,这个看日志有点麻烦,除非你引入 ELK 这种,还有你还要做全链路测试,各种问题。没个半年以上,搞不定的。拆分项目根据业务来拆,不用根据 DDD 来。就 4 台机器,说真的,干不了什么。

    如果你只是要实现功能的话,我劝你还是搞成多模块应用好,把通用模块拆出来(这就是通用域啊),之后再慢慢改成微服务都行。
    oneisall8955
        29
    oneisall8955  
       2021-02-11 13:17:11 +08:00 via Android
    带薪学习?你公司这样的体系怎么感觉会学歪了
    KuoYu
        30
    KuoYu  
       2021-02-11 13:39:06 +08:00 via iPhone
    千万不要!血的教训,在一家初创公司刚开始的时候 leader 就提出微服务 集群等,就 4 个人做这些大坑一个接一个,最后交付期拖了又拖,到我离职都没完成。做个人吧,老老实实传统业务做好做精不好吗?
    tedzhou1221
        31
    tedzhou1221  
       2021-02-11 13:53:09 +08:00
    想起一个互金行业的上市公司的后台,看日志也是上终端看,麻烦死了。后来发现是有 ELK 的,然后他们说不会用。。。。
    optional
        32
    optional  
       2021-02-11 14:12:12 +08:00 via Android
    3 台 k3s,不就啥都有了
    atonku
        33
    atonku  
       2021-02-11 15:41:24 +08:00
    把现在的代码复制一份,部署上去,告诉老板,微服务做好了
    Tarkky
        34
    Tarkky  
       2021-02-11 16:33:02 +08:00
    谁来给扫下忙,微服务到底适用的场景是啥?它的痛点又是啥?谢谢
    winglight2016
        35
    winglight2016  
       2021-02-11 17:23:35 +08:00
    个人看来,9 成 9 的软件是不需要微服务架构的,然而就业市场上吃香,lz 不妨抓住机会学习一下。毕竟这么一大坨技术栈,不在实际项目上应用是想象不出来有多么复杂。好在,你不需要严格划分“微”服务,只需要按子系统分一下,然后能够互相调用就好了,毕竟,能够容器化领导就已经直呼专业了。所以,这种项目真正考验你的不是学习能力,而是项目规划能力,加上服务注册 /发现,错误处理,不就是二期需求了吗?再来一些 k8s,热更新、灰度部署啥的,三期就来了。程序员最重要的能力就是给自己安排合适的工作。。。(🐶
    luzhh
        36
    luzhh  
       2021-02-11 17:49:44 +08:00
    微服务没楼上说的那么恐怖,我当时也是一个人搞微服务项目,一波下来没啥复杂的,但是该有的确实得有,不然那就是挖坑,链路追踪+日志中心得搞好,要不然排查问题特别麻烦。
    abcbuzhiming
        37
    abcbuzhiming  
       2021-02-11 21:10:03 +08:00   ❤️ 1
    @Tarkky 微服务本质是用空间换了复杂度,用体积膨胀,人员膨胀的方式把问题分而化之了。所以如果你的组织度跟不上的话,你解决不了问题,反而问题更多
    abcbuzhiming
        38
    abcbuzhiming  
       2021-02-11 21:12:05 +08:00
    @luzhh 链路追踪和日志中心的成本真高,动不动就是几台服务器,或者要上 ELK 做查询。我其实很早就想把自己的服务拆分化,后来一看我才几台服务器啊。我要拆了得上链路中心和日志中心,搞不好在这上面的服务器比我的应用服务器都多,实在是尴尬。
    xuanbg
        39
    xuanbg  
       2021-02-11 22:37:47 +08:00
    @abcbuzhiming 1 台 4C16G 就够跑 20 来个服务了。。。微服务不一定要多少台服务器,而是适当拆分服务。拆分服务的好处是能够在局部(单个服务)有效降低业务复杂度,使每个服务都容易维护,且整个系统易于扩展,反正就是加个服务(一只羊是赶,一群羊也是放)。
    agagega
        40
    agagega  
       2021-02-11 22:51:49 +08:00 via iPhone
    xcstream
        41
    xcstream  
       2021-02-11 23:48:54 +08:00
    简历上多个可以吹的项目
    mtrec
        42
    mtrec  
       2021-02-12 09:40:35 +08:00 via Android
    支持带薪学习 一套下来也不算太复杂 并发不高的话不觉得有什么谷歌解决不了的坑
    CantSee
        43
    CantSee  
       2021-02-12 21:17:10 +08:00 via Android
    四台服务器搞微服务吗?服务容错会比较低!不过带薪学习也不错
    heart4lor
        44
    heart4lor  
       2021-02-12 22:10:02 +08:00
    集群不一定是高并发场景才适用呀,HA 集群一定程度上也能减少宕机时间,后面业务量上来了直接加实例数也几乎没有技术成本
    lewinlan
        45
    lewinlan  
       2021-02-14 11:13:04 +08:00 via Android
    我觉得楼主只是被那些名词唬住了。
    实际上现在这些事情都有完善的框架实现,一套下来并不复杂,一个人撑起一个运维团队也不是不可能。
    性能损耗也没那么夸张,传统行业的自建服务器比云上的共享服务器强太多了。
    不过要注意那些不可预见的坑,如果领导在这方面经验丰富,能解决难题,那下面的人就放心去做就是了。
    但是看楼主对团队的描述,战斗力很弱的样子……
    所以我猜想你们这个步子的确迈太大了……
    MoccaCafe
        46
    MoccaCafe  
       2021-02-14 11:51:11 +08:00
    同意 11 楼和 13 楼,如果人手不足且时间赶,能不上新技术就不上新技术。按照我以前开发的经验,微服务虽然拆分出来 BIG 更高,但是开发效率降低了,人手不足就算了
    luzhh
        47
    luzhh  
       2021-02-15 17:18:19 +08:00
    @abcbuzhiming 链路追踪没啥成本的,如果存储数据量过大可以设置存储比例。日志中心也不会有啥特别大的成本,无非就是数据存储多久的问题。这些东西听上去很高大上,等你玩过一次就知道其实也没多复杂的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5890 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 02:49 · PVG 10:49 · LAX 18:49 · JFK 21:49
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.