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

微服务真的很好用吗?

  •  2
     
  •   lcdxiangzi · 86 天前 · 5934 次点击
    这是一个创建于 86 天前的主题,其中的信息可能已经有所发展或是发生改变。
    最近在翻 springcloud 的书,也理解微服务相对于单体系统的优势。
    但是,学习过程中,感觉微服务架构带来的新的问题,实在是多,引入了各个模块来解决(打补丁)。

    反观单体系统的问题,我认为大部分问题都是因为系统与业务场景配合不够默契,或者说系统解耦等方面设计不够合理导致的。在原有单体系统的设计思路上,如果可以下功夫去理解业务,从系统架构层面多下功夫(说的很虚,具体的要结合实际情况展开讨论)

    回到现实,很多公司都积极向微服务转型,一些小公司(比如我们自己),就几个人的团队,个人感觉使用微服务并没有能够实现微服务的价值(真正复杂的系统、人头超过一定限度的团队规模可能更容易体现出微服务的价值)

    是不是大家有点无脑跟风的意思啊?

    纯粹个人想法,感兴趣的同学希望可以发表一下意见,多沟通,多学习。谢谢
    59 回复  |  直到 2019-01-24 09:41:26 +08:00
        1
    artandlol   86 天前 via iPhone   ♥ 5
    以前微博崩了,大都打不开,现在微博崩了,还能评论下。
        2
    lhx2008   86 天前 via Android
    是的,大部分就是跟风,单系统没有解决的问题,微服务也不会解决。
        3
    lhx2008   86 天前
    我认为微服务本质上是和人员组织有关的,单系统不适合几百人共同开发,所以才要切分,瞎分不知道有啥意义。
        4
    daveze   86 天前   ♥ 1
    微服务我可以分别上线,分别优化,流量分离,单个服务非常聚焦,服务不要了直接丢弃。
        6
    dynastysea   86 天前
    我觉得和业务形态也有关系,有些业务很适合解耦。即使拆分得很细维护成本也不高。有些则不同,本来耦合就打,拆开反而增加很多链式调用,这样得到的收益可能就不大了
        7
    libook   86 天前   ♥ 6
    软件工程没有银弹,虽然我在用微服务架构,但不鼓励无脑从众,微服务思想只是个工具,在合适的地方好用,在不合适的地方不好用。

    微服务背后其实是计算机科学上降低系统复杂度一种策略——分层解耦。所以只有在某个系统内部因功能互相耦合导致复杂度高的情况才适用,而且用也不是拆得越细越好,因为有些功能从业务上来讲就是一体的,比如订单和商品。

    微服务化之后一方面功能模块之间使用有限的 API 进行沟通,只要 API 不变,内部变化的灵活性很高,不会出现牵一发动全身的问题;另一方面可以按功能模块拆成小团队,便于管理。

    微服务规模到了一定程度就会遇到新的问题,比如一致性、响应时间、容灾,所以做设计的时候要充分考虑清楚得失,看究竟是否划算采用微服务思想。
        8
    lcdxiangzi   86 天前
    @artandlol 微博这种体量,我认为微服务时有意义的,但是除去这些大厂的产品,剩下的绝大多数产品的数量级都要小很多,大家再来套用微服务,成本和收益是否划得来,我觉得是要打问号的。
        9
    lcdxiangzi   86 天前
    @daveze 单个服务聚焦的同时,服务间的调用必然会增多。

    @ all
    其实说白了,这是一个度的问题,每个人对这个度的把握都是不一样的,说到底还是人的问题。。。
        10
    zzzzzzZ   86 天前
    大部分跟风,它只是架构而已,用不用看人

    就像你说的,觉得很多小公司上微服务就是杀鸡用牛刀
    这些年主要是有很多 P2P 公司,或者说金融相关(小额贷等等),它们要做相关的业务,不上就崩
    公司再小也要拿这把牛刀才能砍

    至于整个大环境动不动就谈微服务之类的,都是跟风,你不也最近跟风开始学了吗
        11
    PureWhiteWu   86 天前
    小流量小架构,没必要,微服务会引入很多额外的复杂的问题。
    等真的规模上来了,微服务才有意义。
        12
    passerbytiny   86 天前
    Java 有一个很有意思的名词,企业级应用,以前的 Java EE,现在的 Jakarta EE。如果只是打算做个网站或者业务只有 CRUD,那么用微服务确实自讨苦吃。基本上,主程人数在 10 人以下,或者技术团队 50 人以下,微服务学习一下就行了,别真用。
        13
    lihongjie0209   86 天前   ♥ 4
    [Imgur]( )
    [Imgur]( )
    [Imgur]( )
        14
    ColinWang   86 天前
    可以了解一下康威定律,大概意思就是系统设计的结构必定复制设计该系统的组织的沟通结构。
        15
    ShangAliyun   86 天前
    想明白必要性,在决定用不用。
    我想说的是,面对用户量疯长。能简单的增加服务器数量来增加负载能力,那么微服务这种结构非常适用。
    如果小企业,一个项目到 die 的一天还几百几千用户,那么使用微服务就没意义了
        16
    exiaohao   86 天前   ♥ 2
    ![]( )
        17
    cyril4free   86 天前
    取决于系统够不够大
        18
    jorneyr   86 天前
    可能大项目里的微服务中一个服务就提供上千个 API,而大多数系统可能一起也就提供百八十个 API,所以微到什么样子需要和服务一起讨论,微和不微不同情况下需要量化才知道好不好,没有统一的标准。
        19
    wangxiaoaer   86 天前
    互联网应用可以考虑微服务,企业应用就算了吧,到处复制、到处部署是个问题,虽然 docker 可以解决一些, 但是也麻烦。
        20
    salmon5   86 天前 via Android
    @artandlol 微博多少人的技术团队?市值多少亿?
        21
    luozic   85 天前 via iPhone
    把代码变更和质量成本转嫁到运维和代码,以及规范的成本上。 大厂先天喜欢微服务的原因很简单,人家架构和运维还有基础设施牛逼。 业务代码挫一点也不会咋样。
        22
    maemual   85 天前 via iPhone
    微服务好不好玩取决于你们的运维能力,小团队就别折腾了,给自己添麻烦
        23
    Phariel   85 天前
    搞微服务 还不如把现有纠缠在一起的逻辑搞搞好 本身从上到下逻辑就有问题 拆开来难道就没问题了? 自欺欺人而已
        24
    lcdxiangzi   85 天前
    看了大家的讨论,确认我们属于跟风无疑。无奈领导需要搞花头给大领导看,干活的只能闭着眼上去当炮灰了,O(∩_∩)O~
        25
    lcdxiangzi   85 天前
    @zzzzzzZ 想问一下,为什么 P2P 必须用微服务?是特定时段高并发吗?
        26
    weo0   85 天前
    我们公司微服务就是个笑话,完全跟风,给客户看。
        27
    zzzzzzZ   85 天前
    @lcdxiangzi
    对,核心就是特定时间段的秒杀系统
    P2P 盘子没起来之前怎么办,办活动呗,X 月 X 号整点开放几个利率 20%的项目,每人限购 X 万这种,一场就吸资几百几千万
    其它的也差不多。前两年乌烟瘴气的 P2P 公司,可能公司就几个人,空手套白狼,开几个项目活动就能吸资千万往上
        28
    passerbytiny   85 天前
    @lcdxiangzi 这应该跟 P2P 无关,金融行业都一样。金融行业对高可靠性和低延迟性的要求都很高,就像前几天 PDD 那种情况,在金融行业要是出现了,不跑路就得进去。金融行业的应用,常规 CRUD 架构再怎么改都是撑不起来的,读写分离、事件源这种架构都要上,它们天生就是分布式架构,所以搞成微服务一点难度都没有。
        29
    soulmine   85 天前
    几个人当然没必要啊 好端端的一个单体就能干完的事情 非得要拆 N 个出来 又学不来大厂的那一整套服务注册治理监控的机制 结果就抓瞎了
        30
    specita   85 天前
    感觉没有大厂的资源技术,想搞好很难
        31
    guolaopi   85 天前
    我到现在都搞不清微服务和 soa 的区别。。感觉都是分成多个项目部署啊。。。。。
        32
    dnsaq   85 天前 via iPhone
    没有大厂实力驾驭不了的,小公司不精于自己的业务偏偏要和大厂比高低,可笑的很
        33
    SyncWorld   85 天前
    都是噱头~~一个 TMD 针别大的项目都要跟风玩微服务,只能强行拆,拆完性能还没以前的好~
        34
    dnsaq   85 天前 via iPhone
    @luozic 烂代码转嫁给运维?你觉得架构上怼硬件能解决问题吗?
        35
    yamedie   85 天前
    13 楼和 16 楼的图承包了我一天的笑点 哈哈哈
        36
    yamedie   85 天前
        37
    guanhui07   85 天前
    ![]( ) nice
        38
    CoderGeek   85 天前
    大公司的发展 往后 istio 搭配 springcloud 之类, 小的不推荐用 但个人可以学
        39
    dremy   85 天前 via iPhone
    微服务其实更方便部署吧,先不说 k8s,大多数情况下 docker-compose 用一个配置文件就能解决部署的问题了,还不需要运维去手动安装系统的各种依赖,对运维真的解放很多呢
        40
    alexmy   85 天前
    我感觉看情况了,都是小水管平时没啥事的就不一定用微服务了,当然,要是本身就很熟悉这门技术,又有需求当然好啦。
        41
    lcdxiangzi   85 天前
    @passerbytiny #28 金融行业天生适合微服务吗?按照我对金融业务场景的理解,事务性管理以及业务逻辑严格把控的需求。和微服务不算是很搭吧?
    单说事务性管理,在微服务中就要搞出一堆控件来实现各种补偿机制吧?
    从 CAP 角度来看,我反而觉得金融机构会主动放弃 P,单体系统不是更完美吗?(不考虑项目硬件成本的前提下)

    不知道是不是我没有理解清楚?还是?
        42
    lcdxiangzi   85 天前
    @yamedie #36 我觉得这种调调最要命了,如果单纯从项目发展的角度看,不考虑其他的外围因素。
        43
    lcdxiangzi   85 天前
    @dremy #39 我不是很认同呢,微服务确实配有很多好用的工具,比如 K8S 或者 docker,但是真的复杂业务场景,业务逻辑流程都会变长,在微服务里面,一次优化或者迭代可能就涉及到多个服务模块,在测试或者部署时,模块内部的工作量确实降低了,但是服务间的调用关系和部署顺序,我认为变得复杂的多了。如果考虑到这些技术的出现时间。

    窃以为,这些工具可能就是为了填坑才引进的呢。。。
        44
    demomacro   85 天前
    看到十三楼的,就想到把 shit 山拆成一份份的小 shit...
        45
    passerbytiny   85 天前
    @lcdxiangzi #33 给你说个最简单的例子,从 A 银行转账到 B 银行,你准备做一个怎样的“单体”系统能让 A 银行和 B 银行都接受。
    事务性这个就更扯淡了,就一个最简单的行内取钱操作,就涉及到个人账户、支行账户、总行账户等多方面的数据,想要原子提交,你准备让用户等多久。
        46
    ericls   85 天前 via iPhone
    十个可用性 99%的服务 加起来 就是一个 90% 可用性的服务了

    还不算 传输的 overhead
        47
    lcdxiangzi   85 天前
    @passerbytiny #45 上面这些业务场景我都理解,但是我了解到的大行,确实是原子操作。为什么五大行到现在离不开 IBM 的大机,就是他们为了保住 C 和 A,而不得已,必须放弃 P 了。
    至少我是这样理解的。
        48
    passerbytiny   85 天前
    @lcdxiangzi #39 请举出事实。

    再纠正你一点错误:CAP 是分布式系统的理论,当你讨论到 CAP 的时候,已经是分布式系统了。下面摘自维基百科:

    在理论计算机科学中,CAP 定理( CAP theorem ),又被称作布鲁尔定理( Brewer's theorem ),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:[1][2]

    一致性( Consistency ) (等同于所有节点访问同一份最新的数据副本)
    可用性( Availability )(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
    分区容错性( Partition tolerance )(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在 C 和 A 之间做出选择[3]。)

    根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了 C 性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了 A 性质。除非两个节点可以互相通信,才能既保证 C 又保证 A,这又会导致丧失 P 性质。
        49
    lcdxiangzi   85 天前
    @passerbytiny 这个是我混淆概念了,想表达类似的意思,所以拿过来用了。
        50
    arthas2234   85 天前
    微服务就是扯淡的,就跟区块链一样,是个公司都想插一脚,显得高大上,实际上没有几个用得上。有这个时间还不如把自己的项目优化好
        51
    Kraken   85 天前
    我觉得分布式系统本身就是为了解决高流量下的高并发问题的 小公司确实不适合上微服务 第一项目没到那个体量,第二 上了微服务之后有很多的问题需要解决,比如分布式事务什么的。有解决这些问题的时间,用单机架构可能已经写好上了第一版了,而且流量小的时候也不会崩,项目到了一定体量再考虑重构也不是不行。 不过用 springcloud 对开发来说可以提升技术,没什么不好的。
        52
    lcdxiangzi   85 天前
    https://dzone.com/articles/microservices-please-dont
    这篇文章,大家感兴趣可以看看
        53
    lcdxiangzi   85 天前   ♥ 1
    @guolaopi 我个人的理解,大家谈 SOA 好像更多的是一种架构思路,微服务好像更偏向具体的技术实现。
    我也觉得这两个东西没有太大差别,/DOGE
        54
    guolaopi   85 天前
    @lcdxiangzi 所以就是和十年前的分布式现在叫云了一个意思吗?
        55
    luoer   85 天前
    凡事不是非黑即白的。 一定要说“微服务垃圾”才是正确? 单体系统有单体系统的优势,微服务自然也有也有优劣,技术选型需要对症下药。 我们有时候就是太迷恋新技术新架构,从来不考虑优劣确实是个问题。
        56
    dhq   85 天前
    单机部署多个服务的网络消耗代价也很大吧
        57
    imwalson   85 天前 via Android
    之前的公司两个人开发项目用什么微服务架构,徒增各种各样的麻烦,搞的总是不能按时交付项目,在我看来这种就是盲目跟风的结果
        58
    chanchan   84 天前
    @lihongjie0209 我就知道会有这图 哈哈哈
        59
    linhua   84 天前
    想到了 宏内核( monolithic kernel ) 和 微内核( microkernel )
    Linux 系统就是宏内核 , 而 Google 正在开发的 Fuchsia 系统则是微内核的
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2509 人在线   最高记录 4385   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 20ms · UTC 15:16 · PVG 23:16 · LAX 08:16 · JFK 11:16
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1