owned this note   changed 7 years ago  
Linked with GitHub

微服務的基礎建設 - Service Discovery

tags: DevOpsDays Taipei 2018 9/11 11:20~12:00 Track A

歡迎來到 DevOps Days 2018 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/c/DevOpsDays2018
手機版請點選上方 按鈕展開議程列表。

在大會遇到任何問題都可以在下方的問題回報區中留言
大會問題與建議回報區

Slides / 作者部落格

前言

  • DEV 和 OPS 要成正向的循環
  • 大部分公司的盲點：DEV & OPS 是兩個團隊各跑各的

設計角度
Design for Operation

隨著系統越來越複雜 instance 間的溝通就會越來越複雜，要管理也越來越難

devops-in-redmine

https://www.nginx.com/blog/nginmesh-nginx-as-a-proxy-in-an-istio-service-mesh/

需求一 如何管理八啦八啦

服務 A 要呼叫服務 B (B 有多個而且數量不固定就連 IP 都可能不固定)

  • 要怎麼做呼叫

service-discovery-in-a-microservices-architecture

service Discovery Patterns

這張圖也太長XD
想拍都沒辦法

高整合度的方案： HashiCorp Consul

service side disc Pattern

https://www.nginx.com/blog/service-discovery-with-nginx-plus-and-consul/

client side disc Pattern

https://medium.com/containers-on-aws/how-to-setup-service-discovery-in-elastic-container-service-3d18479959e6

需求2:更靈活的服務調度

案例 跨資料服務中心 跨市場的服務配置策略 該如何配置與實作

需求3:管理外部服務

  • 外部服務不會來我這裡註冊/移除註冊
  • 我無法得知外部服務背後有幾個instance
  • 如何對外部服務做health check

問題4:如何發現『服務發現』？

參考consul官網的架構
consul

每個node配置一個專屬的client
稱為SideCar模式

需求5:如何避免侵入式的問題？

思考：如果每台server都有LB+RP?

SOA –> MicroService Architecture –> Cloud Native Architecture


https://www.facebook.com/photo.php?fbid=10157583170923765&set=a.10150256921053765&type=1

總結

場外聊天室再開

手要舉好幾次好累
不用放下來了

樓上好辛苦…

(想知道)
作者在投影片的「探照燈」效果是怎麼做的?
花錢買
https://www.logitech.com/zh-tw/product/spotlight-presentation-remote

謝謝! (phcome 賣4k 一支, 可以考慮買下來啊)

用 k8s 不就什麼都有了…? service discovery, load balance, health check … 一應俱全
還要看公司政策啊

全新的工具也需要學習曲線啊~

這場很難抓到斷點打成筆記ORZ

感覺需要的先備知識很多…

我幫你去踢講者. (ㄟ .. )

前面有人提到K8s, 高手啊>.<

其實愈來愈多工具被發明出來，目的就是讓把 workload 放到平台上運行這件事情變得更 developer-friendly，不然光是要搞懂今天講的 service discovery 要怎麼做就是一件很複雜的事情，但 k8s 都幫你搞定了，專心在開發就好

k8s + istio ?
yes => service mesh

istio 是目前比較成熟的專案…相對啦…

補充一下，其實很多背景在 40 分鐘內講不完，我用的是 .net, 很多東西看的到用不到啊! service discovery 是介紹背後的原理，consul 只是因為整合度高我拿來當案例而已。比較成熟的是 istio / envoy, k8s 也做掉很多了。沒有自己搞的動機就不要自己弄了，這種年代自己做不划算。不過很多場景是還沒辦法用到 k8s (老舊的系統…) 這時口袋多個 solution 不是件壞事。

Select a repo