Aktywne Wpisy
Bananek2 +59
#!$%@? was wysropki, w paru tematach pisałem eseje tłumacząc różne zagadnienia na co poświęciłem spora część poranka którą mógłbym spędzić inaczej, ale stwierdziłem że pro publico bono czymś się z wami podzielę jakimiś swoimi perspektywami które uważałem za mądre i które możne komuś coś pomogą. Zaglądam zobaczyć czy chociaż ktoś zaplusował, a tam wpisy pokasowane i tyle z tego ogółem.
I was przegrywy też #!$%@?ę, bo myśl o waszej "samotności" chodzi za mną już od przebudzenia. Już nie będę komentować waszej mentalności getto murzynów z USA gdzie "oskarkowanie" jest odpowiednikiem "zachowywaniem się jak biały", bo to inny temat, ale #!$%@?ę tą waszą osmarkaną "samotność".
Siedzieć na tagu latami i nikogo na nim nie poznać to naprawdę trzeba mieć talent. Ciekawe z czego to wynika, może dlatego, że macie po prostu w dupie nawiązanie kontaktu z kimkolwiek. Nie mówię o zarywaniu do loch gdzie faktycznie coś tam trzeba umieć sobą reprezentować, mówię o zwykłym zaproszeniu na wspólnego spierdotripa. Jesteście gorsi od starych bab, które jakoś potrafią się umówić ze sobą na herbatę, herbatnika i na spacer na grzyby. Jesteście "samotni", a kiedy wy się kiedykolwiek kimkolwiek zainteresowaliście, kiedy wy kiedykolwiek kogokolwiek zaprosiliście?
Ja
I was przegrywy też #!$%@?ę, bo myśl o waszej "samotności" chodzi za mną już od przebudzenia. Już nie będę komentować waszej mentalności getto murzynów z USA gdzie "oskarkowanie" jest odpowiednikiem "zachowywaniem się jak biały", bo to inny temat, ale #!$%@?ę tą waszą osmarkaną "samotność".
Siedzieć na tagu latami i nikogo na nim nie poznać to naprawdę trzeba mieć talent. Ciekawe z czego to wynika, może dlatego, że macie po prostu w dupie nawiązanie kontaktu z kimkolwiek. Nie mówię o zarywaniu do loch gdzie faktycznie coś tam trzeba umieć sobą reprezentować, mówię o zwykłym zaproszeniu na wspólnego spierdotripa. Jesteście gorsi od starych bab, które jakoś potrafią się umówić ze sobą na herbatę, herbatnika i na spacer na grzyby. Jesteście "samotni", a kiedy wy się kiedykolwiek kimkolwiek zainteresowaliście, kiedy wy kiedykolwiek kogokolwiek zaprosiliście?
Ja
Jestem teraz na wakacjach all inclusive w Turcji i naszły mnie takie przemyślenia, że ludzie są po prostu okropni i ohydni (oczywiście nie wszyscy, ale chyba większość) :
Chamstwo na każdym kroku, przepychanie się, wpychanie w kolejki,
Patrzenie się chamsko na cycki i dupe w stroju kąpielowym, to że jestem na basenie nie znaczy że chce abyś się na mnie wpatrywał,
Traktowanie innych jak śmieci, zero przepraszam, dziękuję, proszę,
Branie ogromnych ilości jedzenia i picia po to żeby zostawić innym do posprzątania i wyrzucenia,
Walki o leżaki i miejsca do siedzenia, gonitwy i kłótnie z innymi,
Chamstwo na każdym kroku, przepychanie się, wpychanie w kolejki,
Patrzenie się chamsko na cycki i dupe w stroju kąpielowym, to że jestem na basenie nie znaczy że chce abyś się na mnie wpatrywał,
Traktowanie innych jak śmieci, zero przepraszam, dziękuję, proszę,
Branie ogromnych ilości jedzenia i picia po to żeby zostawić innym do posprzątania i wyrzucenia,
Walki o leżaki i miejsca do siedzenia, gonitwy i kłótnie z innymi,
Mam dosyć specyficzną architekturę systemu w startupie, w którym pracuje. Otóż rozwinął się ostatnio mocno i zaczynamy rozkminiać jak niektóre rzeczy zrobić dobrze, żeby działały długoterminowo.
Obracamy się w kontekście AWS.
Mamy na produkcji 3 maszyny EC2, nazwijmy je Alpha, Beta, Gamma.
Na każdej z nich stoi (prawie) dokładnie to samo REST API (w 99% jest to samo, moze sie minimalnie różnić, to bez znaczenia)
Powiedzmy, że chcemy udostępnić zunifikowane API naszym klientom pod 1 domeną. Userzy mogą lets say pobierać/dodawac/modyfikować zamówienia.
będzie to wyglądało np tak:
GET https://api.example/orders/111/products
POST https://api.example/orders/222/products
PATCH https://api.example/orders/333/products
czy coś w stym stylu.
Problem polega na tym, że za order 111 odpowiada EC2 Alpha, za order 222 odpowiada EC2 Beta, a za order 333 odpowiada Gamma.
W związku z czym chciałbym aby:
GET https://api.example/orders/111/products -> pobrało i zwróciło wynik z API z Alphy
POST https://api.example/orders/222/products -> pobrało i zwróciło wynik z API z Bety
PATCH https://api.example/orders/333/products -> pobrało i zwróciło wynik z API z Gammy
Informacje, który order jest obsługiwany przez którą maszyne trzymamy w bazie sqlowej w AWS, takze dostep jest do tego prosty.
Mam kilka pomysłów jak to zrobić, ale chciałbym zapytać czy być może ktoś się spotkał z tego typu problemami i ma pomysł jak to rozwiązać tak, żeby na pewno żaden purysta się do tego nie doczepił.
Moje 2 pomysły to:
1. Skorzystanie z API Gateway + AWS Lambda. Stawiamy API gateway, wystawiamy go pod api.example, gdy przyjdzie request to odpala się lambda, wyciąga order_id z requestu, szuka przypisania orderu z bazy i robi jakiegos curla na tym konkretnym EC2 i zwraca wynik. Boję się, że to będzie wolne i drogie
2. Postawienie 3x API Gateway(per EC2) + Load balancer. W load balancerze definiujemy rules typu jak w path jest "orders/111" to przekieruj na API Gateway Alpha etc.. Orderów nie ma dużo więc takich zasad dużo również by nie było. Wada taka, że jak w systemie pojawi się order to trzeba dodać do load balancera nowy rules, a to jest kolejny kod, który trzeba napisac i utrzymywać.
Jakieś inne pomysły?
#programista15k #programista25k #programowanie #it #pracait
@Gofer33: ale czemu chcesz tak to robic?
1) Użyć Kong/Openresty jak gatewaya - coś w stylu https://openresty.org/en/dynamic-routing-based-on-redis.html / https://konghq.com/blog/engineering/how-to-dynamically-route-requests-with-kong-enterprise
2) (imo najlepsza opcja) Zacząć generować IDki zamówień tak żeby Alpha zawsze generowała id zaczynające się od 1, beta od 2 itd. Wtedy bardzo łatwo skonfigurujesz sobie API Gatewaya żeby matchował "/1*", "/2*" itd.
3) Napisać osobny serwis który zwróci lokalizację danego zamówienia i proxy uderzy po nie. Nginx ma taki
@Gofer33: To na #!$%@? wam architekt skoro wiecie lepiej?
Lambda tu raczej się nie sprawdzi, bo chcesz trzymać połączenia pomiędzy proxy a serwisem dla minimalizowania opóżnień.
Co do technologii to pewnie wybrałbym Rust (lepiej), Go (gorzej) lub cokolwiek w miarę wydajnego. Jak to będzie prosta przelotka, która przepisuje headery i streamuje message to narzut
Problem zupełnie inny, ale było tam trochę o przkierowaniach - ale jestem leniwy i nie chce mi się oglądać znowu czy sobie czegoś nie uroilem, to tylko zerknij ;-)
Jak już chcesz robić na ec2 to powinieneś mieć jedną do której się łączy i ona pobiera sobie dane z konkretnej maszyny.
@PanJanuszTrzeci:
słabo się znam na AWS, ale po co takie customowe rozwiązania na AWS stosować? to chyba sensowniej API gateway + lambda + redis.
Serwer proxy który pyta bazę i wie do jakiego serwera uderzyć. Jeśli dane są duże to zamiast przekazywać dane zwraca redirect 3xx na odpowiedni serwer docelowy. Większość klientów http automatycznie to obsługuje ale robi drugi request. Jeśli dane są małe to nie opłaca się nawiązywać osobnego połączenia przez klienta.
Sam kiedyś miałem podobną architekturę ale dynamiczną i nie po http. Mieliśmy Master serwer który non stop monitorwał wszystkie inne serwery(był
też się za łeb złapałem, ależ #!$%@?
tam coś nielogicznego na bank jest robione, jeszcze z tą bazą danych, która trzyma order id - id maszynki xD
@ksos: tylko jak powiesz proxy jaki order ma iść do jakiego serwera. Gdzieś musisz mieć kod, który wyciąga informację z bazy i coś z nią robi. Może to być proxy, może to być konfiguracja load balancera, ale coś to musi być
@zibizz1: to byłoby najprostrze, ale trochę słabe z punktu widzenia UX jak i wydajności. Raz, że klient może nie obsługiwać redirectów (jak np.
curl
bez odpowiedniej flagi). Dwa, że to dodatkowe blokujące zapytanie na które trzeba poczekaćjeśli cache "mapujący" odpada, ale dane końcowe nie zmieniają się zbyt często, to można ew. pomyśleć o cachowaniu ostatecznego wyniku poprzez CDN z jakimś sensownym max-age.
ogólnie ciężko powiedzieć co będzie najlepsze, takimi decyzjami powinny sterować metryki i priorytety architektoniczne. dużo