IT过去几年趋势，你们知道的大公司转到cloud/microservice的web application系统performance/cost有提高吗 -anji(f.free) @枫下论坛 The Rolia Forum

工作学习 / 事业工作 / IT过去几年趋势，你们知道的大公司转到cloud/microservice的web application系统performance/cost有提高吗 -anji(f.free); 2021-2-27 {546} (#13544075@0)
Web app几乎都转了javascript framework, client rendering, micro service deploy in cloud, security所需每call一个 micro service得先拿token (数百mili sec), token对security要求高的系统大约15分钟就失效，所以基本不停重拿。micro service每个end point deploy on 1 VM. Each VM minimum 2G, 这样下来monolith一个4-8G支持几百个web service, 现在2G X 100了。总之，front end migrate到javascript framework on cloud, back end micro service on cloud的系之几年折腾下来，你们所见的performance cost都怎么样？还不提database可能被分成无数个之间备份去支持micro service了。

现在的趋势是，不要和我谈性能，能真正干活你就赚了大便宜了。 -guestagain(guest again); 2021-2-27 (#13544082@0) +1

绕不过去啊，call SaaS时需要两级token 6-800 minsec不见了系统还没干活呢。另前后俩部分头拿到第一个cloud账单都嚎叫。。。 -anji(f.free); 2021-2-27 (#13544092@0)

被忽悠的多了去了，但是趋势就是趋势，不跟着跑很多东西都不方便。 -guestagain(guest again); 2021-2-27 (#13544099@0)

所以说聪明人是少数人，他们知道什么东西适合在什么地方，愚蠢的人看到一个东西流行就扑上去，结果白白浪费了时间和精力 -wuyg719(平平); 2021-2-27 (#13544109@0) +6

对，听说啥热门就要上啥，一团糟。 -guestagain(guest again); 2021-2-27 (#13544118@0) +3

其实很多应用不适合micro service，这个架构只适合startup公司和云服务公司，传统的银行和保险的大部分业务不适合这个模式 -wuyg719(平平); 2021-2-27 (#13544102@0) +4

谢谢。这么说你在银行和保险业看到这个practice的结果是negative对吗？i.e, performance没提高目前也还没省钱。 -anji(f.free); 2021-2-27 (#13544133@0) +1

大部分应用是不适合micro service，但不能一概而论，比如我公司有一个灾难模拟软件，就非常适合micro services：因为它需要处理海量数据 -wuyg719(平平); 2021-2-27 (#13544139@0)

难道不是没有安全漏洞，就算胜利？ -troyd(Troy); 2021-2-27 (#13544165@0)

呵呵，业务都没法正常运行的话，谁管你安全漏洞呀。 -guestagain(guest again); 2021-2-27 (#13544171@0)

这些都有解决办法：比如可以自己在企业内网颁发token，database自动备份自动恢复，可以放在一个物理服务器，表分组，service自动scale，需要的时候才起来，没有做不到的事情，只用愚蠢的设计人员 -wuyg719(平平); 2021-2-27 (#13544095@0) +2

你说的都做到了啊，问的是做到后你见到的perf/cost如何？ -anji(f.free); 2021-2-27 (#13544101@0) +1

这些我都做过，但挡不住愚蠢的领导，很多应用不适合microservice，请看我上面的回复 -wuyg719(平平); 2021-2-27 (#13544106@0)
micro services是没有办法的办法，很多公司的业务系统因为其他原因做不动了，领导不懂，然后被忽悠以为这个是银弹，其实银弹只有几个：深入了解业务，找到最适合的技术架构 -wuyg719(平平); 2021-2-27 (#13544120@0) +1

嗯，最怕就是不管实际的业户需求，为了micro而把逻辑unit拆的一塌糊涂。 -guestagain(guest again); 2021-2-27 (#13544131@0)
MicroService每多一层就会多一层接口，维护这些接口比传统的架构更麻烦，如果业务简单这样问题不大，但如果业务复杂，接口的成本会迟早拖垮整个系统 -wuyg719(平平); 2021-2-27 (#13544132@0)

传统的架构通过编译错误很早就可以发现接口的错误，但micro services没有这个能力了，所以只能通过单元测试来保障接口向后兼容，但很多公司根本不重视单元测试，到了集成阶段才发现接口错误！ -wuyg719(平平); 2021-2-27 (#13544158@0) +1

我当时写了一个service，其中的一个接口有两百个左右的字段，为了保障接口的统一，我被迫在调用端和被调用端两头都写了一堆unit test去测试接口是否正确，这个代价让我深深感到害怕：以后怎么维护这个接口？ -wuyg719(平平); 2021-3-2 (#13549744@0)

但对于social network一类的软件micro services就很好用：他们的业务相对简单，但用户数很高，而且用户数变化很快 -wuyg719(平平); 2021-2-27 (#13544159@0) +4

“micro service每个end point deploy on 1 VM.Each VM minimum 2G”--不知道这个endpoint怎么理解。一般来说一个microservice常常对应一个 domain (DDD 概念)， -xmlhttprequest(build5381); 2021-2-27 {159} (#13544168@0)
所以不应该那么多（具体多少看情况）。如果是指 REST API endpoint - 那应该用 serverless (比如 aws lambda / azure function) -- 一般比起 vm 便宜得多（看具体流量）。

我一般建议：每个 domain 有自己的 microservice - 具体需要多大容量看这个 domain 具体要求。第三方集成比如 webhook 或偶尔调一下的优先考虑 serverless。但一定要提前计算 traffic / cost。 -xmlhttprequest(build5381); 2021-2-27 (#13544178@0) +1
另外，micro-service + serverless 的主要卖点是 scale out -- 系统的 performance 的瓶颈（比如你提及的 token）要另行解决。 -xmlhttprequest(build5381); 2021-2-27 (#13544183@0)

传统的银行保险的用户数是基本固定的，访问量很容易估算出来，所以scale up没有多大用，那些Internet公司用这个刚好 -wuyg719(平平); 2021-2-27 (#13544189@0)

首先，是 scale out 不是 scale up。其次，“银行用户数是固定的”，但领导画大饼时会说我们 2 年内将有 3X 的增长 --- 这时候你可以说 -- 没问题，我们的设计能够 auto-scaling，今天不需要多付一分钱，而明年 3X 了不需要有任何改动。 -xmlhttprequest(build5381); 2021-2-27 (#13544194@0)

我承认用错了词，应该用scale out，但scale out已经存在了几十年了，那个cluster就是干这个的，当然cluster只能适合几倍的scale out，micro service能搞几十倍的scale out，但问题是银行有几十倍的需求吗？ -wuyg719(平平); 2021-2-27 (#13544196@0)

我上面提 scale out，回答的是题主问的 performance 问题。银行的情况可以这样理解 -- monolithic system 也可以用 cluster 来做到 scale out (一定程度)，但如果拆分更细成 micro-services，每一小块可以拥有不同的 scale -- 设计正确的话，会更优。 -xmlhttprequest(build5381); 2021-2-27 (#13544210@0)

系统的成本包括开发和运维，你这样做运行成本降了，但维护开发的成本上升了 -wuyg719(平平); 2021-2-27 (#13544235@0) +1

有可能 --- 但 cloud computing 不就是解决这个问题么 - CI/CD 部署，auto-scaling，'Infrastructure as Code'... 目标应该是降低运维。 -xmlhttprequest(build5381); 2021-2-27 (#13544244@0)

以前是运维的人在管理生产环境，现在把运维的人砍了，但你得写部署文件，所以你得多招一个部署开发人员，你觉得你省钱了吗？ -wuyg719(平平); 2021-2-27 (#13544259@0)

lol -- 我们公司是 dev 写 CI/CD pipeline, terraform, etc etc --- 而且加活儿不加薪，所以你要是问我们大老板，我猜他会说 “省大发了” 。 -xmlhttprequest(build5381); 2021-2-27 (#13544268@0)

我还忘了说，开发一个micro services的难度更高，开发成本更高 -wuyg719(平平); 2021-2-27 (#13544272@0)

怎么会？大部分公司的难点在于业务逻辑一锅粥，否则的话从 monolithic 系统转成 micro-service，相当于把一百万行 code 分成 n 个独立包装 - 如此而已。不过我承认，把 micro-service 系统（子系统之间） *设计* 好，不容易。 -xmlhttprequest(build5381); 2021-2-27 (#13544282@0)

micro services需要维护之间的接口，这个是多出的成本，传统的系统一个refactor就搞定了，非常容易 -wuyg719(平平); 2021-2-27 (#13544285@0)

这个就看怎么平衡了 -- 比如 refactoring 完了改一行 code，全部重测 3 个月，然后重新部署整个系统 shutdown 8 小时... -xmlhttprequest(build5381); 2021-2-27 (#13544292@0)

refacor是机器在维护接口的统一，micro service是靠人工写的test cases去检查接口的统一，refactor当然容易得多 -wuyg719(平平); 2021-2-27 (#13544296@0)

这个就看设计的好坏了 -- bounded context, versioning 等等等等。所以说 business arch 和 solution arch 的鸭梨山大。 -xmlhttprequest(build5381); 2021-2-27 (#13544303@0)

你觉得找一个合格的arch很容易？ -wuyg719(平平); 2021-2-27 (#13544309@0)

应该还算容易吧 --- 根据您的问题和我的回答，我觉得我应该能拿 60 分吧 lol -xmlhttprequest(build5381); 2021-2-27 (#13544312@0)

合格的arch不仅要懂技术，而且要懂业务，我相信在外面找到合格的技术人员还有可能，要找到两个都懂的人很难很难 -wuyg719(平平); 2021-2-27 (#13544318@0) +1

LOB 的业务变化比起 internet media 行业要慢很多，比起技术更新也要慢很多，所以花够时间就行 --- 但要是跨行业跳槽一开始就很辛苦。 -xmlhttprequest(build5381); 2021-2-27 (#13544323@0)

一般的技术牛人在大部分公司是个宝，人家愿意从头再来？那你给他arch的工资还是developer的工资？ -wuyg719(平平); 2021-2-27 (#13544330@0)

你敢说你的一个基础service改了接口和功能，你就不需要全部重测了？你现在有更多的麻烦，因为你不知道哪个模块出了问题，每个模块是不同的team用不同的语言开发的，你得一个team一个team找过去，他们不停地踢皮球，你怎么办？ -wuyg719(平平); 2021-2-27 (#13544302@0)

呵呵。越来越像 technical interview 了，还是用的 team 实战的场景 / 例子。我答不出来了 lol -xmlhttprequest(build5381); 2021-2-27 (#13544308@0)

有时候一些问题很难说是一个模块的问题，是一个相互配合的问题，然后每个team都指望其他team去修复问题，都指望自己轻松一些，这个就是扯皮的问题 -wuyg719(平平); 2021-2-27 (#13544311@0) +1

讲真，这个问题太大了 -- solution arch 在制定 architectural guidelines 时，应该有怎样的 power / authority 来 enforce 这些标准? 我也母鸡啊... lol -xmlhttprequest(build5381); 2021-2-27 (#13544317@0)

如果arch每天要去解决这些扯皮的问题，那他还有时间干更重要的活吗？而且arch一般不喜欢干这个得罪人的活，传统的PM又搞不清究竟该归谁。 -wuyg719(平平); 2021-2-27 (#13544320@0)

lol 这个就看具体公司了吧 -- 要是 arch + dm + pm 把几个 lead 找来一起开个会还不能解决任何问题，用 monolithic 系统估计也悬 lol... -xmlhttprequest(build5381); 2021-2-27 (#13544331@0)

monolithic 责任就是自己的, 从头搞到尾, 你躲不掉 -wuyg719(平平); 2021-3-2 (#13548356@0)

还有一种扯皮: 某service有一个bug, 其开发人员为了掩盖错误, 利用其强势地位, 硬说没有错误, 把责任推给其他services, 造成成本大幅度升高 -wuyg719(平平); 2021-3-2 (#13548350@0) +2

有些模块很好划分，但有些模块不好划分，你想当然划好了，可业务人员一提新需求你就傻眼了：怎么会这样？！ -wuyg719(平平); 2021-2-27 (#13544289@0)

把几个模块拆拆合合不需要成本？ -wuyg719(平平); 2021-2-27 (#13544293@0)
这个是对的 -- 我一向说，micro-service 最大的挑战是 business reconsolidation -- business architect 和 solution architect 的压力最大 --- 但如果设计得当，回报很大。 -xmlhttprequest(build5381); 2021-2-27 (#13544298@0)

你这个设计得当的假设在很多公司不成立，大部分公司都充满了滥竽充数的人 -wuyg719(平平); 2021-2-27 (#13544329@0)

lol 这个... 你可千万别去和老板说，咱公司可不能用 micro-services，咱公司的人都是滥竽充数的... 这可不好... lol -xmlhttprequest(build5381); 2021-2-27 (#13544338@0)

所以我尽量躲着，等他们碰了钉子就知道厉害了 -wuyg719(平平); 2021-2-27 (#13544369@0)

我还忘记说了, Micro Services 还有另外一个陷阱: 技术碎片, 传统的monolithic 逼迫你使用统一的语言, 现在没有了这个限制,大家就开始乱来了, 趁手上有人懂Lisp, 用它也搞了一个Service. 每个service用不同的语言,你以后怎么维护呀? -wuyg719(平平); 2021-3-2 (#13548564@0)

我在这里分享的呢，基本上都是我所在公司的实战经验，有挑战，有难点，有需要平衡的地方，但总的来说，µServices 好处不少。你分享的这些是你听说的呢，还是实际使用经验？ -xmlhttprequest(build5381); 2021-3-2 (#13549455@0)

这些就是我们公司的实战遇到的问题，我们的头现在正处于焦头烂额的状态 -wuyg719(平平); 2021-3-2 (#13549630@0)

你要是一个公司把 µServices 能犯的错误差不多都犯齐了 -- 倒也挺厉害的... -xmlhttprequest(build5381); 2021-3-2 (#13549640@0)

我很早以前就跟他们说过，别以为micro services很容易，那是入门容易，后面难，可他们不听，几个主力程序员被迫跳槽，经理焦头烂额 -wuyg719(平平); 2021-3-2 (#13549647@0)

我当时用了一个比喻：总司令说要打下一个山头，据估计大约有一个连的敌人，给你三个连拿下它，结果冲到一半才发现敌人有一个团 -wuyg719(平平); 2021-3-2 (#13549651@0)

你们不会是既没有 business architect 也没有 solution architect 吧，完全是程序员“乱来” （引用你的话）。 -xmlhttprequest(build5381); 2021-3-2 (#13549658@0)

我们有business architect和solution architect，都被打入冷宫，因为都不看好这个方向，我们有一个傻瓜software architect，基本没有实战经验，以为自己找到了银弹，能吹会说，说服了CTO -wuyg719(平平); 2021-3-2 (#13549667@0)

这基本上是管理问题，就等于大家都搞电动车，也不是每家都行的。 -sxffff(lookingforjob); 2021-3-2 (#13549753@0)

我觉得正好相反 -- 开始规划时难（也不是难，而是需要仔细规划），后面就越来越容易，享受到好处了。 -xmlhttprequest(build5381); 2021-3-2 (#13549652@0)

要是这么容易也没有那么多程序员被迫跳槽，当时我们部门一个月走了四个资深程序员 -wuyg719(平平); 2021-3-2 (#13549662@0)

你问的这些问题呢，怎么说呢？认真地回答：有时候这个 lambda 用 nodejs，那个用 java --- 其实反倒是最佳选择。但你举的很多反例，都是“如果有敌人故意捣乱，µServices 就会出问题！” 所以我觉得好像是我太认真回答楼主的技术问题了。 -xmlhttprequest(build5381); 2021-3-2 (#13549462@0)

用nodejs还好，从UI挖人过来就可以了，就怕人傻搞什么php或ruby等，到时哭都来不及了 -wuyg719(平平); 2021-3-2 (#13549655@0)

呃，从 UI 挖人来写 lambda nodejs? 也不是不行，不过... 呃...现在我有点儿明白了 lol... -xmlhttprequest(build5381); 2021-3-2 (#13549666@0)

市面上没有多少人真搞过nodejs，还不是让一部分js developer客串 -wuyg719(平平); 2021-3-2 (#13549674@0)

looool 说实话我真的搞不清你是说真的，还是开玩笑 / 抬杠 / 活跃气氛... 我老得查一下我是不是走错版块了 lol... -xmlhttprequest(build5381); 2021-3-2 (#13549700@0)

你不会觉得nodejs是一种独立的语言吧？ -wuyg719(平平); 2021-3-2 (#13549707@0)

lol 不是因为这个... -xmlhttprequest(build5381); 2021-3-2 (#13549712@0)

其实micro servics还是有优点的：传统的运维人员不懂系统，出了问题还得找开发人员，开发人员对系统更了解，所以能够更准确调整硬件 -wuyg719(平平); 2021-2-27 (#13544278@0)

准确来讲这不是micro services专有的，传统的系统也可以自动部署，但传统系统部署很容易，所以一般懒得去自动部署，所以micro services又多了一条罪状，把部署搞得很复杂不得不上自动部署 -wuyg719(平平); 2021-2-27 (#13544306@0)

每个developer的时间和能力是有限的, 如果任务多了就只能推迟任务完成的时间, 你觉得省大发了? -wuyg719(平平); 2021-3-2 (#13548536@0)

搞这个从来不是为了省钱。你公司还在用COBOL,能招到年轻人吗，招到了，能留住吗？例如对24/7service up的支持，micro service 要好很多，这个要多花钱去实现。年轻人就想搞复杂的东西，就得让他们搞，你不能指望竞争对手都搞不出来，然后你就不用搞了。 -sxffff(lookingforjob); 2021-3-2 (#13548700@0)

如果真有一个系统用cobol搞了几十年，你真觉得用micro services就能搞定？在没有micro services之前我们早早就有了web services 和rpc等分布式计算，你又怎么觉得micro srrvices就是银弹呢？下次我再搞个nano services是不是要推倒重来？ -wuyg719(平平); 2021-3-2 (#13548740@0)

为什么cobol搞了几十年就不能有取代方案呢？事实是很多的cobol已经被取代了。 -sxffff(lookingforjob); 2021-3-2 (#13549174@0)

Cobol被取代不是micro service的功劳，在这之前就基本被取代了 -wuyg719(平平); 2021-3-2 (#13549636@0)

举个例子来说，本来一个 monolithic 大系统，需要 4 台 100 个cpu的 servers，但 *如果* 能拆分成 A, B, C, D.... 没准儿 A 需要 2X2cpu，B: 4X8cpu, C: 2X4cpu，D: lambda --- 每天晚上 A, M, Q 可以 shutdown 8 小时 etc... -xmlhttprequest(build5381); 2021-2-27 (#13544236@0)

对于低廉的硬件，高昂的人工，你这套方案看上去并不省钱 -wuyg719(平平); 2021-2-27 (#13544243@0)

cloud computing + serverless + devops... 的目标是降低人工干预。 -xmlhttprequest(build5381); 2021-2-27 (#13544245@0)
另外，monolithic 的成本不是简单的 “硬件” 成本问题 -- 多数 monolithic 系统只能 scale up 不能 scale out，所以 vendor (比如数据库厂家)看准这点，狂收企业级（比如 64cpu）版本费用。 -xmlhttprequest(build5381); 2021-2-27 (#13544255@0)

水平问题。刚开始都要绕冤枉路的。 -negation(否定之否定); 2021-2-27 (#13544791@0)
interrupted very often -daydayup88888(每天进步一点点); 2021-3-2 (#13549517@0)
不是马工但是大概模模糊糊听懂了你的意思。想起一个故事，几十年前上世纪末参观石青云院士的指纹识别系统，识别一个指纹要几分钟，有学生说好慢，石教授气定神闲地说，不怕 -w4b(w4b); 2021-3-2 {54} (#13549715@0)
硬件速度会很快上来的。

今天，一个破手机就能做指纹识别
很好的讨论, 学习中 -markham016(markham2016); 2021-3-3 (#13550164@0)

IT过去几年趋势，你们知道的大公司转到cloud/microservice的web application系统performance/cost有提高吗

Replies, comments and Discussions:

More Topics