作者:
jej (晃奶大馬桶)
2019-01-22 14:31:42如題
話說google號稱他們
每天要重開服務好幾千台
這段野史開啟了台灣微服務的歷史
就我們公司用的微服務來說
目前看起來是看錯誤log更難了
要往不同的service去找
有時候系統掛了還不是自己系統的問題
(有可能是我們公司系統間相依性太高)
處於越末梢的服務越可憐
就像是物料的供應鏈一樣
原物料有問題 客人買到抗議
只能一關一關往上找
就這樣看起來我們公司的微服務算是失敗的
有沒有哪位大大也有用微服務
來分享一下 是真的有像google他們說的
這麼好？
作者:
jimmy689 (å‰ç±³è›†è›†)
2019-01-22 14:35:00信徒會跟你縮要把Log本身也變一個服務
作者:
alihue (wanda wanda)
2019-01-22 15:08:00人家谷歌專案規模多大，沒幾千行的程式也跟人家搞微服務
可以研究一下服務調用鏈，例如zipkin,eagleeye
作者: weinine32 (隨意) 2019-01-22 15:33:00
可以考慮用splunk
Log要做中央集權式ELK stack or Splunk
問題就是相依性不能太高啊XDD 各自獨立要有好的 unit, integration, e2e test 方便限縮問題點，最好還有一些自動偵錯 (例如 AWS CloudWatch)，才能發揮他的好處
你自己的缺陷都講完了還要怪罪微服務，這就是做半套而已呀。
作者:
Masakiad (Masaki)
2019-01-22 18:30:00同樓樓上，log沒整合的問題跟微服務架構本身無關。先不說microservice了，光cluster就要整合log了
作者:
johnny94 (32767)
2019-01-22 19:15:00沒有到一定的規模就搞微服務只是自討苦吃而已
一堆人在那邊跟風，相關配套都沒...這篇就是標準的例子
就跟一堆公司跟風找數據科學家一樣 根本就是鼻屎大的數據而已 也在那邊亂搞
作者:
pttworld (批踢踢世界)
2019-01-23 11:41:00博弈產業也有微服務的例子
作者: lnmlee 2019-01-24 12:11:00
storage service database 都有cluster？ group?
作者:
bitcch (必可取)
2019-01-24 13:24:00(有可能是我們公司系統間相依性太高)
作者: rocwild (外國死小孩) 2019-01-24 15:51:00
整合一下log.看看correlation id的文章吧
作者:
abcorz (robin)
2019-01-25 23:45:00graylog看看