O alternativă la JAR-urile JARs Hacker News
Așteptați până când vor afla cât de rapide sunt apelurile funcționale în proces decât RPC-urile.
Folosesc un cadru la Google care se bazează pe microservicii și permite compunerea microservicilor într-un ansamblu. În cadrul unui ansamblu, apelurile între servicii se fac în proces; dacă apelezi un serviciu într-un alt ansamblu, acesta trebuie să facă un RPC.
Mecanica dacă este vorba de un apel local sau de un RPC este tratată la nivelul cadrului. Acest lucru face ca împărțirea unui serviciu în propriul său ansamblu să fie o sarcină simplă (nu trebuie să actualizați niciun cod, ci doar configurarea; acest lucru poate fi gestionat de SRE).
Seamănă mult cu OTP.
În Java-land, puteți, de asemenea, să aveți clientul și serviciul dvs. să utilizeze aceeași interfață. Doar injectați diferite implementări pentru local și la distanță.
Odată ce v-ați confruntat cu probleme de a genera automat lipici între interfața locală și obiectul la distanță, devine simplu să interpuneți alte lucruri utile - verificări de securitate, tranzacții dacă utilizați o bază de date relațională etc. Puteți chiar să aveți codul de lipici care să instanțeze leneș componentele serviciului, deci nu este nevoie să le încărcați până când un client nu face un apel.
Totuși, ți-ai dori un nume interesant. Extrem de legare Java? Autobuz Jet îmbunătățit? Excelentă Joy Bringer?
Sincer, dacă nu poți avea încredere în dezvoltatorii tăi să nu facă o mizerie într-un monolit, nu poți avea încredere în ei să nu facă o mizerie distribuită cu microservicii.
Ambele modele arhitecturale își au utilizările. Niciunul dintre ei nu vă va salva de dezvoltatorii răi.
M-aș putea înșela și în acest sens, dar îmi place microserviciul după ce proiectele ating o anumită dimensiune.
Cu un singur spațiu de memorie este ușor să parcurgi pur și simplu orice arhitectură pe care ar trebui să o urmezi.
Microserviciile nu rezolvă bile de noroi, dar pot îngreuna formarea și formarea mai ușoară a punctelor.
Nu este un panaceu, se pare că doar împingi complexitatea într-un alt loc.
Și nu, nu panaceu, doar un mod de gândire care cred că este util.
Sunt un mare fan al unui SOA bine conceput, dar acest lucru nu este blogabil în mod corespunzător aici în 2016.
Acum, OK, ecosistemului JVM îi lipsește un sistem de module bun în acest moment. Dar Java 9 o va remedia. Există, de asemenea, OSGi, deși nu știu prea multe despre asta.
Împingerea complexității pe comunicarea între proces și mașină va duce doar la niveluri mai ridicate de spaghete. Chiar crezi că aceiași oameni care ar construi un monolit prost ar face o treabă mai bună construind un sistem distribuit?
Nu vreau să fiu prea dogmatic; există cazuri de utilizare legitime pentru servicii. Sunt doar foarte sceptic cu privire la microservicii ca soluție pentru complexitate.
2017 va fi anul întoarcerii monolitului: „Cum am înlocuit 946 de microservicii cu un binar de rugină legat static de 10kB și cum nu ne-a salvat în mod extrem de lipsa noastră completă de ceva asemănător unui model de afaceri coerent”.
Acum că legea lui Moore se epuizează, ne putem aștepta în mod rezonabil să devină falsă în următorul deceniu. Împărțirea dintre cei care pot scrie doar cod și cei care pot proiecta în mod corespunzător sisteme software va deveni prea evidentă atunci.