Sa Internet (service mesh), ug ania ang lain. Hooray! Pero ngano man? Dayon, gusto nakong ipahayag ang akong opinyon nga ang mga service meshes mas maayo unta 10 ka tuig na ang milabay, sa wala pa ang pag-abut sa mga container platform sama sa Docker ug Kubernetes. Wala ako nag-ingon nga ang akong punto sa panglantaw mas maayo o mas grabe pa kay sa uban, apan tungod kay ang mga service meshes komplikado nga mga mananap, daghang mga punto sa panglantaw makatabang aron mas masabtan kini.
Maghisgot ako bahin sa plataporma sa dotCloud, nga gitukod sa kapin sa usa ka gatos nga microservice ug gisuportahan ang libu-libo nga mga aplikasyon sa mga sulud. Akong ipasabut ang mga hagit nga among nasugatan sa pagpalambo ug paglansad niini, ug kung sa unsang paagi makatabang ang mga meshes sa serbisyo (o dili).
kasaysayan sa dotcloud
Nasulat na nako ang bahin sa kasaysayan sa dotCloud ug ang pagpili sa arkitektura alang sa kini nga plataporma, apan wala kaayo maghisgot bahin sa layer sa network. Kung di ka ganahan mubasa mahitungod sa dotCloud, ania ang kinatibuk-an niini: kini usa ka PaaS platform-as-a-service nga nagtugot sa mga kliyente sa pagpadagan sa usa ka halapad nga mga aplikasyon (Java, PHP, Python...), uban ang suporta alang sa usa ka halapad nga serbisyo sa datos ( MongoDB, MySQL, Redis...) ug usa ka workflow sama sa Heroku: imong gi-upload ang imong code sa plataporma, kini nagtukod og mga hulagway sa sudlanan ug nag-deploy niini.
Isulti ko kanimo kung giunsa ang trapiko gipadala sa platform sa dotCloud. Dili tungod kay kini labi ka bugnaw (bisan kung ang sistema nagtrabaho og maayo alang sa iyang panahon!), Apan sa panguna tungod kay sa tabang sa modernong mga himan, ang ingon nga disenyo dali nga mapatuman sa mubo nga panahon sa usa ka kasarangan nga grupo kung kinahanglan nila ang usa ka paagi sa ruta. trapiko tali sa usa ka hugpong sa mga microservice o usa ka hugpong sa mga aplikasyon. Sa ingon, mahimo nimong itandi ang mga kapilian: kung unsa ang mahitabo kung imong pauswagon ang tanan sa imong kaugalingon o mogamit usa ka naa na nga serbisyo sa mesh. Standard nga pagpili: paghimo sa imong kaugalingon o pagpalit.
Pag-ruta sa trapiko alang sa gi-host nga mga aplikasyon
Ang mga aplikasyon sa dotCloud mahimong ibutyag ang HTTP ug TCP endpoints.
Mga endpoint sa HTTP dinamikong gidugang sa load balancer cluster configuration . Susama kini sa gibuhat sa mga kahinguhaan karon sa Kubernetes ug usa ka load balancer sama .
Ang mga kliyente nagkonektar sa HTTP nga mga endpoint pinaagi sa angay nga mga domain, kung ang domain name nagpunting sa dotCloud load balancers. Walay espesyal.
TCP endpoints nakig-uban sa usa ka numero sa pantalan, nga ipasa sa tanan nga mga sudlanan sa kana nga stack pinaagi sa mga variable sa palibot.
Ang mga kliyente makakonektar sa TCP endpoints gamit ang angay nga hostname (sama sa gateway-X.dotcloud.com) ug port number.
Kini nga hostname nagsulbad sa "nats" server cluster (walay kalabotan sa ) nga magruta sa umaabot nga mga koneksyon sa TCP ngadto sa husto nga sudlanan (o, sa kaso sa mga serbisyo nga balanse sa pagkarga, ngadto sa husto nga mga sudlanan).
Kung pamilyar ka sa Kubernetes, lagmit makapahinumdom kini kanimo sa mga serbisyo .
Walay serbisyo nga katumbas sa dotCloud nga plataporma : alang sa kayano, ang pag-access sa mga serbisyo nahitabo sa parehas nga paagi gikan sa sulod ug gawas sa plataporma.
Ang tanan organisado nga yano: ang orihinal nga pagpatuman sa HTTP ug TCP routing networks lagmit pipila lang ka gatos nga linya sa Python. Yano (ako moingon, walay pulos) nga mga algorithm nga gidalisay sa pagtubo sa plataporma ug sa pagtunga sa dugang nga mga kinahanglanon.
Ang halapad nga refactoring sa kasamtangan nga code wala gikinahanglan. Sa partikular, direktang makagamit sa adres nga nakuha pinaagi sa environment variables.
Sa unsang paagi kini lahi gikan sa usa ka modernong serbisyo nga mata?
Limitado pagkakita. Wala kami bisan unsang mga sukatan alang sa TCP routing mesh. Pag-abut sa pag-ruta sa HTTP, ang mas bag-o nga mga bersyon adunay detalyado nga mga sukatan sa HTTP nga adunay mga code sa sayup ug mga oras sa pagtubag, apan ang mga moderno nga mga meshes sa serbisyo nagpadayon pa, nga naghatag panagsama sa mga sistema sa pagkolekta sa sukatan sama sa Prometheus, pananglitan.
Ang visibility importante dili lang sa operational point of view (aron makatabang sa troubleshoot sa mga problema), apan usab kung ang mga bag-ong feature ipagawas. Naghisgot bahin sa luwas ΠΈ .
Episyente sa pagruta limitado usab. Sa dotCloud routing mesh, ang tanan nga trapiko kinahanglan nga moagi sa usa ka pungpong sa gipahinungod nga mga routing node. Nagpasabot kini nga posibleng motabok sa daghang mga utlanan sa AZ (availability zone) ug usa ka dakong pagtaas sa latency. Nahinumdom ko sa troubleshooting code nga naghimo ug kapin sa usa ka gatos ka SQL nga mga pangutana kada panid ug nagbukas ug bag-ong koneksyon sa SQL server para sa matag pangutana. Kung modagan sa lokal, ang panid mo-load dayon, apan sa dotCloud nagkinahanglan kini og pipila ka mga segundo aron makarga tungod kay ang matag koneksyon sa TCP (ug ang sunod nga SQL query) nagkinahanglan og napulo ka milliseconds. Niini nga partikular nga kaso, ang padayon nga koneksyon nakasulbad sa problema.
Ang mga moderno nga mga meshes sa serbisyo mas maayo sa pag-atubang sa ingon nga mga problema. Una sa tanan, ilang gisusi nga ang mga koneksyon giruta sa tinubdan. Ang lohikal nga dagan parehas: ΠΊΠ»ΠΈΠ΅Π½Ρ β ΠΌΠ΅Ρ β ΡΠ΅ΡΠ²ΠΈΡ, apan karon ang mesh nagtrabaho sa lokal ug dili sa hilit nga mga node, mao nga ang koneksyon ΠΊΠ»ΠΈΠ΅Π½Ρ β ΠΌΠ΅Ρ lokal ug paspas kaayo (microseconds imbes milliseconds).
Ang mga modernong service meshes nagpatuman usab ug mas maalamong load balancing algorithms. Pinaagi sa pag-monitor sa kahimsog sa mga backend, makapadala sila og daghang trapiko sa mas paspas nga mga backend, nga moresulta sa mas maayo nga kinatibuk-ang pasundayag.
Kasegurohan mas maayo usab. Ang dotCloud routing mesh bug-os nga nagdagan sa EC2 Classic ug wala mag-encrypt sa trapiko (ubos sa pangagpas nga kung adunay usa nga nakahimo sa pagbutang usa ka sniffer sa trapiko sa network sa EC2, naa ka sa dako nga problema). Ang mga moderno nga mga meshes sa serbisyo klaro nga nanalipod sa tanan namong trapiko, pananglitan, uban ang mutual TLS authentication ug sunod-sunod nga pag-encrypt.
Pag-ruta sa trapiko alang sa mga serbisyo sa plataporma
Okay, nahisgutan namon ang trapiko tali sa mga aplikasyon, apan komosta ang dotCloud platform mismo?
Ang plataporma mismo naglangkob sa mga usa ka gatos nga microservice nga responsable sa lainlaing mga gimbuhaton. Ang uban nagdawat sa mga hangyo gikan sa uban, ug ang uban mga trabahante sa background nga nagkonektar sa ubang mga serbisyo apan wala sila modawat sa mga koneksyon sa ilang kaugalingon. Sa bisan asa nga kaso, ang matag serbisyo kinahanglan mahibal-an ang mga endpoint sa mga adres nga kinahanglan nga makonektar niini.
Daghang mga serbisyo sa taas nga lebel ang mahimong mogamit sa routing mesh nga gihulagway sa ibabaw. Sa pagkatinuod, daghan sa labaw sa XNUMX ka dotCloud microservices ang na-deploy isip regular nga mga aplikasyon sa dotCloud platform mismo. Apan ang usa ka gamay nga gidaghanon sa mga serbisyo sa ubos nga lebel (ilabi na, kadtong nagpatuman niini nga routing mesh) nanginahanglan usa ka butang nga labi ka simple, nga adunay gamay nga pagsalig (tungod kay dili sila makasalig sa ilang kaugalingon sa pagtrabaho - ang maayo nga daan nga problema sa manok ug itlog).
Kini nga ubos nga lebel, hinungdanon nga mga serbisyo gipakatap pinaagi sa pagpadagan sa mga sudlanan nga direkta sa pipila ka mga yawe nga node. Sa samang higayon, ang standard nga mga serbisyo sa plataporma wala maapil: linker, scheduler, ug runner. Kung gusto nimo itandi sa mga modernong sudlanan nga plataporma, kini sama sa paglansad sa usa ka kontrol nga eroplano nga adunay docker run direkta sa mga node, imbes nga itugyan ang buluhaton sa Kubernetes. Parehas kaayo kini sa konsepto , nga naggamit o kung nag-boot sa usa ka standalone cluster.
Kini nga mga serbisyo gibutyag sa yano ug dili maayo nga paagi: ang YAML file naglista sa ilang mga ngalan ug adres; ug ang matag kliyente kinahanglang mokuha ug kopya niining YAML file alang sa pag-deploy.
Sa usa ka bahin, kini hilabihan ka kasaligan, tungod kay wala kini magkinahanglan og suporta sa usa ka eksternal nga yawe/bili nga tindahan, sama sa Zookeeper (hinumdomi, etcd o Consul wala pa niadtong panahona). Sa laing bahin, kini nagpalisud sa pagbalhin sa mga serbisyo. Matag higayon nga ang usa ka lakang gihimo, ang tanan nga mga kliyente kinahanglan nga makakuha usa ka na-update nga YAML file (ug mahimoβg i-reload). Dili kaayo komportable!
Pagkahuman, nagsugod kami sa pagpatuman sa usa ka bag-ong laraw, diin ang matag kliyente konektado sa usa ka lokal nga proxy server. Imbis sa adres ug pantalan, kinahanglan ra nga mahibal-an ang numero sa pantalan sa serbisyo, ug magkonektar pinaagi sa localhost. Ang lokal nga proxy nagdumala niini nga koneksyon ug nagpasa niini ngadto sa aktuwal nga server. Karon kung ibalhin ang backend sa lain nga makina o pag-scale, imbes nga i-update ang tanan nga mga kliyente, kinahanglan ra nga i-update ang tanan nga mga lokal nga proxy; ug ang reboot dili na kinahanglan.
(Giplano usab nga i-encapsulate ang trapiko sa mga koneksyon sa TLS ug i-install ang lain nga proxy server sa nakadawat nga bahin, ingon man susihon ang mga sertipiko sa TLS nga walaβy pag-apil sa serbisyo sa pagdawat, nga gi-configure aron makadawat mga koneksyon lamang sa localhost. Dugang pa niana sa ulahi).
Kini susama kaayo sa gikan sa Airbnb, apan ang mahinungdanong kalainan mao nga ang SmartStack gipatuman ug gipakatap sa produksyon, samtang ang internal nga routing system sa dotCloud na-boxed sa dihang ang dotCloud nahimong Docker.
Personal nakong gikonsiderar ang SmartStack nga usa sa mga nag-una sa mga sistema sama sa Istio, Linkerd ug Consul Connect tungod kay silang tanan nagsunod sa samang sumbanan:
- Pagdalag proxy sa matag node.
- Ang mga kliyente nagkonektar sa proxy.
- Ang control plane nag-update sa proxy configuration kung ang mga backend mausab.
- β¦ Kita!
Modernong Serbisyo Mesh Implementasyon
Kung kinahanglan naton nga ipatuman ang parehas nga grid karon, magamit naton ang parehas nga mga prinsipyo. Pananglitan, paghimo og internal nga DNS zone pinaagi sa pagmapa sa mga ngalan sa serbisyo ngadto sa mga adres sa kawanangan 127.0.0.0/8. Dayon pagdagan ang HAProxy sa matag cluster node, pagdawat sa mga koneksyon sa matag adres sa serbisyo (sa subnet 127.0.0.0/8) ug pag-redirect/pagbalanse sa load ngadto sa angay nga mga backend. Ang pag-configure sa HAProxy mahimong madumala , nga nagtugot kanimo sa pagtipig sa impormasyon sa backend sa etcd o Consul ug awtomatikong iduso ang updated nga configuration ngadto sa HAProxy kon gikinahanglan.
Ingon niini ang pagtrabaho ni Istio! Apan sa pipila ka mga kalainan:
- Mga gamit imbes nga HAProxy.
- Gitipigan ang pag-configure sa backend pinaagi sa Kubernetes API imbes sa etcd o Consul.
- Ang mga serbisyo gigahin nga mga adres sa internal nga subnet (mga adres sa Kubernetes ClusterIP) imbes nga 127.0.0.0/8.
- Adunay usa ka dugang nga sangkap (Citadel) aron idugang ang us aka TLS nga panghimatuud tali sa kliyente ug mga server.
- Nagsuporta sa bag-ong mga bahin sama sa circuit breaking, distributed tracing, canary deployment, etc.
Atong tan-awon dayon ang pipila sa mga kalainan.
Sugo nga Proxy
Ang Envoy Proxy gisulat ni Lyft [kakompetensya sa Uber sa merkado sa taxi - gibanabana. matag.]. Susama kini sa daghang mga paagi sa ubang mga proxy (eg HAProxy, Nginx, Traefik...), apan gisulat ni Lyft ang ilang kaugalingon tungod kay nanginahanglan sila mga bahin nga wala sa ubang mga proxy ug ingon og mas makatarunganon nga maghimo usa ka bag-o kaysa sa pag-extend. usa ka kasamtangan.
Ang envoy mahimong gamiton sa iyang kaugalingon. Kung ako adunay usa ka piho nga serbisyo nga kinahanglan nga magkonektar sa ubang mga serbisyo, mahimo nako kini i-set up aron makonektar sa Envoy ug dayon dinamikong i-configure ug i-reconfigure ang Envoy sa lokasyon sa ubang mga serbisyo, samtang nakakuha daghang daghang mga ekstra sama sa visibility. Imbis usa ka kostumbre nga librarya sa kliyente o pag-injection sa code sa pagsubay sa tawag, nagpadala kami og trapiko sa Envoy, ug nagkolekta kini og mga sukatan alang kanamo.
Apan si Envoy makahimo usab sa pagtrabaho ingon data eroplano (data plane) para sa service mesh. Kini nagpasabut nga karon alang sa kini nga serbisyo nga mesh, ang Envoy gi-configure kontrol nga eroplano (kontrol nga eroplano).
Kontrola nga eroplano
Sa control plane, si Istio nagsalig sa Kubernetes API. Kini dili kaayo lahi sa paggamit sa confd, nga nagsalig sa etcd o Consul sa pagpangita sa usa ka hugpong sa mga yawe sa datastore. Gitan-aw ni Istio ang usa ka hugpong sa mga kapanguhaan sa Kubernetes pinaagi sa Kubernetes API.
Taliwala niini ug unya: Ako mismo nakakaplag niini nga mapuslanon nga mabasa:
Ang Kubernetes API Server usa ka "stupid server" nga nagtanyag og storage, versioning, validation, update, ug API resource semantics.
Ang Istio gidisenyo aron magtrabaho uban sa Kubernetes; ug kung gusto nimo nga gamiton kini sa gawas sa Kubernetes, nan kinahanglan nimo nga magsugod sa usa ka pananglitan sa Kubernetes API server (ug ang etcd helper service).
Mga Address sa Serbisyo
Ang Istio nagsalig sa mga adres sa ClusterIP nga gigahin sa Kubernetes, mao nga ang mga serbisyo sa Istio makakuha usa ka internal nga adres (dili sa sakup 127.0.0.0/8).
Ang trapiko sa usa ka ClusterIP nga adres alang sa usa ka piho nga serbisyo sa usa ka Kubernetes cluster nga walay Istio gibabagan sa kube-proxy ug gipadala ngadto sa likod nga bahin sa proxy. Kung interesado ka sa teknikal nga mga detalye, ang kube-proxy nagtakda sa mga lagda sa iptables (o mga IPVS load balancer, depende kung giunsa kini gi-configure) aron isulat pag-usab ang destinasyon nga mga adres sa IP sa mga koneksyon nga moadto sa adres sa ClusterIP.
Kung ma-install na ang Istio sa usa ka kumpol sa Kubernetes, walaβy mabag-o hangtod nga kini klaro nga magamit alang sa usa ka gihatag nga konsumedor, o bisan ang tibuuk nga namespace, pinaagi sa pagpaila sa usa ka sudlanan. sidecar sa custom pods. Kini nga sudlanan magsugod sa usa ka Envoy nga pananglitan ug magbutang usa ka hugpong sa mga lagda sa iptables aron mabalda ang trapiko nga moadto sa ubang mga serbisyo ug i-redirect ang trapiko sa Envoy.
Kung gisagol sa Kubernetes DNS, kini nagpasabut nga ang among code mahimong magkonektar pinaagi sa ngalan sa serbisyo, ug ang tanan "nagtrabaho lang". Sa laing pagkasulti, ang among code nag-isyu sa mga pangutana sama sa http://api/v1/users/4242unya api pagsulbad sa hangyo alang sa 10.97.105.48, ang mga iptables nga mga lagda makapugong sa mga koneksyon gikan sa 10.97.105.48 ug i-redirect kini ngadto sa lokal nga Envoy proxy, nga ipasa ang hangyo ngadto sa aktuwal nga API backend. Phew!
Dugang nga mga frills
Naghatag usab ang Istio og end-to-end encryption ug authentication pinaagi sa mTLS (mutual TLS). Gitawag ang component palacio.
Adunay usab usa ka sangkap mixer, nga mahimong pangayoon sa Envoy matag usa hangyo nga maghimo usa ka espesyal nga desisyon bahin sa kana nga hangyo depende sa lainlaing mga hinungdan sama sa mga ulohan, pag-load sa backend, ug uban pa... isip proxy).
Ug, siyempre, among gihisgutan ang visibility: Ang Envoy nagkolekta og daghang mga sukatan samtang naghatag og gipang-apod-apod nga pagsubay. Sa usa ka arkitektura sa microservices, kung ang usa ka hangyo sa API kinahanglan nga moagi sa microservices A, B, C, ug D, unya sa pag-login, ang giapod-apod nga pagsubay magdugang usa ka talagsaon nga identifier sa hangyo ug itago kini nga identifier pinaagi sa mga subrequest sa tanan nga kini nga mga microservice, nga gitugotan. aron makuha nimo ang tanan nga may kalabutan nga mga tawag, ang ilang mga paglangan, ug uban pa.
Pagpalambo o pagpalit
Ang Istio adunay reputasyon nga usa ka komplikado nga sistema. Sa kasukwahi, ang pagtukod sa routing mesh nga akong gihulagway sa sinugdanan niini nga post sayon ββββra sa kasamtangan nga mga himan. Busa, makatarunganon ba ang paghimo sa imong kaugalingon nga mesh sa serbisyo?
Kon kita adunay kasarangan nga mga panginahanglan (wala kita magkinahanglan og visibility, usa ka circuit breaker ug uban pang mga subtleties), unya ang mga hunahuna moabut mahitungod sa pagpalambo sa atong kaugalingong himan. Apan kung mogamit kami og Kubernetes, mahimo nga dili na kinahanglan tungod kay ang Kubernetes naghatag na sa mga batakang himan alang sa pagdiskobre sa serbisyo ug pagbalanse sa load.
Apan kung kita adunay mga advanced nga kinahanglanon, nan ang "pagpalit" sa usa ka serbisyo nga mesh ingon usa ka labi ka maayo nga kapilian. (Dili kini kanunay usa ka "pagpalit" tungod kay ang Istio bukas nga gigikanan, apan kinahanglan pa namon nga mamuhunan sa oras sa engineering aron masabtan, ma-deploy, ug madumala kini.)
Unsa ang pilion: Istio, Linkerd o Consul Connect?
Hangtod karon, Istio ra ang among gihisgutan, apan dili lamang kini ang service mesh. Ang popular nga alternatibo mao ang , apan adunay labaw pa .
Unsa ang pilion?
Sa tinuod lang, wala ko kabalo. Sa pagkakaron wala nako isipa ang akong kaugalingon nga may igong katakos sa pagtubag niini nga pangutana. Adunay pipila uban sa pagtandi niini nga mga himan ug bisan pa .
Ang usa ka maayong paagi mao ang paggamit sa usa ka himan sama . Nagpatuman kini og abstraction layer aron pasimplehon ug mahiusa ang mga API nga gihatag sa mga service meshes. Imbis nga makat-on sa espesipiko (ug, sa akong opinyon, medyo komplikado) nga mga API sa lain-laing mga service meshes, mahimo namong gamiton ang mas simple nga SuperGloo nga mga konstruksyon - ug dali nga mobalhin gikan sa usa ngadto sa lain, ingon nga kami adunay intermediate configuration format nga naghulagway sa HTTP interface ug backends. makahimo sa pagmugna sa aktuwal nga configuration alang sa Nginx, HAProxy, Traefik, Apache...
Nagdula ko og gamay sa Istio ug SuperGloo, ug sa sunod nga artikulo gusto nakong ipakita kung unsaon pagdugang ang Istio o Linkerd sa usa ka kasamtangan nga cluster gamit ang SuperGloo, ug kung unsaon pagbuhat sa naulahi ang trabaho niini, nga mao, kini nagtugot kanimo sa pagbalhin gikan sa usa ka serbisyo nga mata sa lain nga walaβy pagsulat pag-usab sa mga pag-configure.
Source: www.habr.com