Mikroserwisy Spring Cloud na AWS

0

Cześć, tym razem ja przychodzę z konkretnym pytaniem :) Czy ktoś z Was wdrażał produkcyjnie (tzn. jest to używane przez użytkowników innych niż developerzy) mikroserwisy na AWS korzystając ze stacku Spring Cloud? Jeśli tak to:

  1. W jaki sposób ogrywaliście service discovery? Eureka czy „natywne” rozwiązania AWS - chyba Route53 to się nazywa, czyli LB po DNS. A może jeszcze jakoś inaczej?
  2. W jaki sposób ogrywaliście konfigurację i hasełka? Config Server czy jakiś własny Vault, Zookeeper, etcd?
  3. Z jakiej usługi skorzystaliście? EKS, ECS, „gołe” EC2?

Dzięki za odpowiedzi.

2

Spring Cloud to raczysko.
A Eureka napisana w Javie to po prostu kupa...

Ogolnie couplowanie "infry" z jakims frameworkiem to słaby pomysl.

2
  1. Service Discovery, Kubernetes EKS ma wbudowane + R53 lub jakiś Consul
  2. Config tez Kubernetes, lub jakiś SSM
  3. Sekrety też Kubernetes + sops z AWS KMS
  4. EKS

Większy problem z jakimś api gateway + bff.

Większość firm nie powinna używać mikroserwisow ani kubertesa. Joł

Jak już Kubernetes to lepiej GCP.

0

@karsa: dzięki za odpowiedź. Potwierdziłeś poniekąd moje przypuszczenia, że lepiej odpalać apki Spring Bootowe na k8s i olać te zabawki typu Eureka. Jedyne co mnie przeraża to utrata kontroli nad rozrastającym się stackiem, ale może właśnie dlatego wymyślono DevOps :)

Swoją drogą ciekawa jaka jest przyszłość i zasadność używania w 2020 stacku Spring Cloudowego (Eureka, Ribbon, Config Service, Zuul), podczas gdy mamy do dyspozycji k8s (on prem albo managed jak EKS) i service meshe typu Istio.

0

Co prawda nie cloud ale mamy eurekę. Ogólnie działa, ale raz na kilka tygodni potrafi się zaciąć tak, ze potrzebny jest restart

0
  1. Ogólnie w wszystkich projektach wystarczały mi zwykłe Service-y z Kubernetesa (czyli odpytywanie po DNS), ale to były mniejsze stosy. W większych pewnie byłoby krucho, zwłaszcza przy jakichś skomplikowanych regułach load-balancingu.

  2. Spring Cloud Config Server to moim zdaniem super sprawa - cała konfiguracja w repozytorium (wszystkie zalety Gita, pull requesty, branche, widać kto zepsuł xD), hierarchiczna struktura, deploy to banał (1 adnotacja + parę envów), apki odpytują config po HTTP.

  3. EKS jest fajna i wygodna, ale jest też droga. Natomiast k8s daje na tyle fajne abstrakcje, że o ile nie wchodzi się za mocno w integrację z konkretną usługą, to migracja do innej chmury jest w miarę bezbolesna.

4

Jeszcze raz powtórzę, większość Waszych fantastycznych CRUDow nie potrzebuje ani mikroserwisow ani kubertesa.

Modularny Monolit zazwyczaj sprawdzi się dużo lepiej.

Starczy do tego jakiś dockera hosting, jakieś AppEngine na GCP i będzie banglac.

Nie jesteście Netflixem i nie macie ich problemów, nie twórzcie sobie tych problemów z czapy bo się wam nudzi. Biznes nie zarabia na zabawie.

1

Dodam również tragiczny moduł do SQS, który jest tak napisany, że aplikacja nie jest w stanie przetwarzać więcej niż 10 wiadomości jednocześnie, bo wspomniany moduł odpytuje o wiadomości jednym żądaniem.

https://github.com/spring-cloud/spring-cloud-aws/issues/166

0

Ja polecam architekture single microservice.

1 użytkowników online, w tym zalogowanych: 0, gości: 1