Java Microservices үчүн колдонмо. 3-бөлүк: жалпы суроолор

Java микросервистерин которуу жана адаптациялоо : Практикалык колдонмо . Жол көрсөткүчтүн мурунку бөлүктөрү:

• микросервистин негиздери жана алардын архитектурасы ;
• микросервистерди жайылтуу жана сыноо .

Абстракттуу нерселерден баштап, конкреттүү китепканаларга чейин Javaдагы микросервистердин мүнөздүү көйгөйлөрүн карап көрөлү.

Java микросервисин кантип ийкемдүү кылуу керек?

Эсиңизде болсун, сиз микросервистерди түзүп жатканда, сиз синхрондуу HTTP чалуулары же асинхрондук билдирүүлөр үчүн JVM ыкмасынын чалууларын соодалайсыз. Методду чалуу негизинен бүтүрүүгө кепилдик берилгени менен (күтүлбөгөн JVM өчүрүлүшүнө тыюу салуу), тармактык чалуу демейки боюнча ишенимсиз. Ал иштеши мүмкүн, бирок ар кандай себептерден улам иштебей калышы мүмкүн: тармак ашыкча жүктөлгөн, жаңы брандмауэр эрежеси ишке ашырылган ж.б.у.с. Мунун кандайча өзгөргөнүн көрүү үчүн, келгиле, BillingService мисалын карап көрөлү.

HTTP/REST ийкемдүүлүк үлгүлөрү

Келгиле, кардарлар компанияңыздын веб-сайтынан электрондук китептерди сатып алса болот дейли. Бул үчүн, сиз жаңы эле PDF эсеп-фактураларын түзүү үчүн интернет-дүкөнүңүздү чакыра турган эсеп-кысап микросервисин ишке киргиздиңиз. Азырынча биз бул чалууну синхрондуу түрдө HTTP аркылуу жасайбыз (бирок бул кызматты асинхрондуу чакыруу алда канча акылга сыярлык, анткени PDF генерациясы колдонуучунун көз карашы боюнча заматта болбошу керек. Ушул эле мисалды кийинкисинде колдонобуз. бөлүмүн жана айырмачылыктарды карагыла).

@Service
class BillingService {

    @Autowired
    private HttpClient client;

     public void bill(User user, Plan plan) {
        Invoice invoice = createInvoice(user, plan);
        httpClient.send(invoiceRequest(user.getEmail(), invoice), responseHandler());
        // ...
    }
}

Жыйынтыктап айтканда, бул HTTP чалуусунун үч мүмкүн болуучу натыйжасы.

• Макул: чалуу болду, аккаунт ийгorктүү түзүлдү.
• КЕЧИКТИРҮҮ: Чалуу аткарылды, бирок аяктоо өтө көпкө созулду.
• ERROR. Чалуу ишке ашкан жок, сиз туура келбеген сурам жөнөткөн болушуңуз мүмкүн же система иштебей жатат.

Кандай гана программа болбосун, ийгorктүү болгондорду гана эмес, ката кырдаалдарды да чечиши керек. Ошол эле микросервистерге да тиешелүү. Жеке микросервистерди жайылтуу жана чыгарууну баштагандан кийин, API'нин бардык орнотулган versionлары шайкеш келишин камсыз кылуу үчүн кошумча күч-аракет жумшоо керек болсо да. Карай турган кызыктуу жагдай - кечигүү маселеси. Мисалы, жооп берүүчүнүн микросервисинин катуу диски толуп, жооп берүү үчүн 50 мс эмес, 10 секунд талап кылынат. Белгилүү бир жүктөмдү сезгениңизде, БиллингСервисиңиздин жооп бербегендиги тутумуңуз аркылуу каскаддай баштаганда ого бетер кызыктуу болот. Иллюстрациялуу мисал катары, ашкананы акырындап бардык ресторан официанттарынын "блогун" баштаганын элестетиңиз. Бул бөлүм микросервистин туруктуулугу темасына толук баяндама бере алbyte, бирок ал иштеп чыгуучуларга бул чындыгында биринчи релизге чейин көңүл бурулбай турган жана көңүл бурулбай турган нерсе экенин эскертет (тажрыйбадан караганда, бул тез-тез болуп турат. жок). төмөнкү). Кечигүүлөр жана каталарга чыдамдуулук жөнүндө ойлонууга жардам берген популярдуу китепкана - Netflixтин Hystrix. Теманы тереңирээк изилдөө үчүн анын documentтерин колдонуңуз.

Кабарлашуунун туруктуулугунун үлгүлөрү

Келгиле, асинхрондук байланышты кененирээк карап чыгалы. Биздин BillingService программабыз эми жазышуу үчүн Spring жана RabbitMQ колдонуп жатабыз деп ойлосок, ушундай көрүнүшү мүмкүн. Каттоо эсебин түзүү үчүн, биз азыр биздин RabbitMQ билдирүү брокерине билдирүү жөнөтөбүз, ал жерде жаңы билдирүүлөрдү күтүп жаткан бир нече жумушчулар бар. Бул жумушчулар PDF эсеп-фактураларын түзүп, аларды тиешелүү колдонуучуларга жөнөтүшөт.

@Service
class BillingService {

    @Autowired
    private RabbitTemplate rabbitTemplate;

     public void bill(User user, Plan plan) {
        Invoice invoice = createInvoice(user, plan);
        // преобразует счет, например, в json и использует его How тело messages
        rabbitTemplate.convertAndSend(exchange, routingkey, invoice);
        // ...
    }
}

Потенциалдуу каталар азыр бир аз башкача көрүнөт, анткени сиз синхрондуу HTTP туташуусундагыдай дароо ОК же КАТА жоопторун албайсыз. Анын ордуна, бизде ката кетиши мүмкүн болгон үч мүмкүн болгон сценарий болушу мүмкүн, алар төмөнкү суроолорду жаратышы мүмкүн:

1. Менин билдирүүм жеткирилди жана кызматкер тарабынан колдонулдубу? Же жоголдубу? (Колдонуучу эсеп-дүмүрчөктү алbyte).
2. Менин билдирүүм бир гана жолу жеткирилдиби? Же бир нече жолу жеткирorп, бир гана жолу иштетилгенби? (Колдонуучу бир нече эсеп-фактураларды алат).
3. Конфигурация: "Мен алмашуу үчүн туура маршруттук ачкычтарды/аттарды колдондумбу" дегенден "Менин билдирүү брокерим туура конфигурацияланганбы жана сакталганбы же анын кезектери толдубу?" (Колдонуучу эсеп-дүмүрчөктү алbyte).

Ар бир асинхрондук микросервистин ийкемдүүлүк үлгүсүнүн деталдуу сүрөттөлүшү бул колдонмонун алкагына кирбейт. Бирок, туура багытта белгилер бар. Мындан тышкары, алар билдирүү технологиясына көз каранды болот. Мисалдар:

• Эгер сиз ActiveMQ сыяктуу JMS ишке ашырууларын колдонуп жатсаңыз, эки фазалуу (XA) милдеттенмелердин кепилдиги үчүн ылдамдыкты алмаштыра аласыз.
• Эгер сиз RabbitMQ колдонуп жатсаңыз, адегенде бул колдонмону окуп чыгыңыз, андан кийин ырастоолор, каталарга чыдамдуулук жана жалпысынан билдирүү ишенимдүүлүгү жөнүндө жакшылап ойлонуңуз.
• Балким, кимдир бирөө Active же RabbitMQ serverлерин конфигурациялоону жакшы билет, айрыкча кластерлөө жана Докер менен айкалыштырып (кимдир бирөө? ;))

Кайсы алHow Java микросервистери үчүн эң жакшы чечим болмок?

Бир жагынан алганда, сиз, мисалы, Spring Boot сыяктуу абдан популярдуу опцияны орното аласыз . Бул .jar файлдарын түзүүнү абдан жеңилдетет, Tomcat же Jetty сыяктуу орнотулган веб-server менен келет жана аны тез жана каалаган жерден иштетүүгө болот. Микросервис тиркемелерин куруу үчүн идеалдуу. Жакында, бир нече адистештирилген микросервис алHowтары пайда болду, Kubernetes же GraalVM , жарым-жартылай реактивдүү программалоодон шыктанган. Бул жерде дагы бир нече кызыктуу атаандаштар бар: Quarkus , Micronaut , Vert.x , Helidon . Акыр-аягы, сиз өзүңүздүн тандооңузга туура келет, бирок биз сизге бир нече сунуштарды бере алабыз, алар толугу менен стандарттуу эмес: Spring Boot кошпогондо, бардык микросервис алHowтары, адатта, укмуштуудай тез, дээрлик бир заматта ишке киргизүү менен сатылат. , эстутумдун аз колдонулушу, чексиздикке чейин масштабдуулугу. Маркетинг материалдары, адатта, платформаны бегемоттун жазгы бутунун жанындагы же бири-бирине көрсөткөн таасирдүү графиканы камтыйт. Бул, теориялык жактан алганда, эски долбоорлорду колдогон иштеп чыгуучулардын нервдерин бошотот, аларды жүктөөгө кээде бир нече мүнөт талап кылынат. Же булутта иштеген иштеп чыгуучулар, алар учурда 50 мс ичинде канча микроконтейнер керек болсо, ошончолук микроконтейнерди баштоону/токтотууну каалашат. Бирок маселе, бул (жасалма) жылаңач металлды ишке киргизүү жана кайра жайгаштыруу убакыттары долбоордун жалпы ийгorгине эч кандай салым кошпойт. Жок дегенде алар күчтүү инфраструктурага, күчтүү documentтерге, коомчулукка жана күчтүү иштеп чыгуучу көндүмдөрүнө караганда азыраак таасир этет. Демек, аны мындай караган жакшы: Эгерде азырынча:

• Жөнөкөй иш процесстери үчүн жүздөгөн суроолорду жаратып, ORM'лериңиздин кеңири жайылышына жол бересиз.
• Орточо татаал монолитти иштетүү үчүн чексиз гигаbyteтар керек.
• Сизде ушунчалык көп code бар жана татаалдыгы ушунчалык жогору (биз азыр Hibernate сыяктуу потенциалдуу жай баштоочулар жөнүндө сөз кылбайбыз), андыктан колдонмоңузду жүктөө үчүн бир нече мүнөт талап кылынат.

Эгер ошондой болсо, анда кошумча микосервис маселелерин кошуу (тармактын ийкемдүүлүгү, билдирүү алмашуу, DevOps, инфраструктура) бош Hello, world жүктөгөнгө караганда долбооруңузга көбүрөөк таасир этет. Жана иштеп чыгуу учурунда кайра жайгаштыруу үчүн, сиз JRebel же DCEVM сыяктуу чечимдерге ээ болушуңуз мүмкүн . Келгиле, Саймон Браундун цитатасын кайталап көрөлү : " Эгерде адамдар монолиттерди (тез жана эффективдүү) кура албаса, алар түзүлүшүнө карабастан (тез жана эффективдүү) микросервистерди курууда кыйынчылыкка туш болушат ." Ошентип, алHowтарыңызды акылдуулук менен тандаңыз.

Кайсы китепканалар синхрондуу Java REST чалуулары үчүн эң жакшы?

Төмөнкү деңгээлдеги техникалык жагында сиз төмөнкү HTTP кардар китепканаларынын бирине ээ болосуз: Javaнын жергorктүү HttpClient (Java 11ден бери), Apache's HttpClient же OkHttp . Эски жакшы JAX-RS кардарларынан заманбап WebSocket кардарларына чейинки башка варианттар бар болгондуктан, мен бул жерде "балким" деп айтып жатканыма көңүл буруңуз . Кандай болгон күндө да, тенденция HTTP кардарын түзүү, өзүңүз HTTP чалуулары менен алпурушуудан баш тартуу. Бул үчүн, сиз OpenFeign долбоорун жана андан ары окуу үчүн баштапкы чекит катары анын documentтерин карап чыгышыңыз керек .

Асинхрондук Java билдирүүлөрү үчүн мыкты брокерлер кайсылар?

Кыязы, сиз популярдуу ActiveMQ (Классикалык же Artemis) , RabbitMQ же Kafka менен таанышасыз .

• ActiveMQ жана RabbitMQ салттуу, толук кандуу билдирүү брокерлери. Алар "акылдуу брокердин" жана "акылсыз колдонуучулардын" өз ара аракеттенүүсүн камтыйт.
• Тарыхый жактан алганда, ActiveMQ жеңил киргизүүнүн (сыноо үчүн) пайдасына ээ болгон, аны RabbitMQ/Docker/TestContainer орнотуулары менен жумшартууга болот.
• Кафканы салттуу "акылдуу" брокер деп атоого болбойт. Анын ордуна, бул акылдуу керектөөчүлөрдү иштетүүнү талап кылган салыштырмалуу "дудук" билдирүүлөр дүкөнү (лог файлы).

RabbitMQ (же башка салттуу билдирүү брокерлери) же Кафканы качан колдонууну жакшыраак түшүнүү үчүн, башталгыч чекит катары бул негизги постту карап көрүңүз . Жалпысынан алганда, билдирүү брокери тандап жатканда, жасалма аткаруу себептерин этибарга албай аракет. Командалар жана онлайн коомчулуктар RabbitMQ канчалык ылдам жана ActiveMQ канчалык жай экени жөнүндө дайыма талашып-тартышып турган учур болгон. Эми RabbitMQ боюнча да ушундай эле аргументтер айтылып жатат, алар секундасына 20-30 миң билдирүү менен жай иштейт дешет. Кафка секундасына 100 миң билдирүү жазат. Ачыгын айтканда, мындай салыштыруулар жылуу менен жумшакты салыштыргандай. Кошумчалай кетсек, эки учурда тең өткөрүмдүүлүк баалуулуктары Alibaba Groupтун төмөнкү жана орто диапазондо болушу мүмкүн. Бирок, чындыгында мындай масштабдагы долбоорлорду (мүнөтүнө миллиондогон билдирүүлөр) учурашыңыз күмөн. Алар сөзсүз бар жана аларда көйгөйлөр болмок. Башка 99% "кадимки" Java бизнес долбоорлорунан айырмаланып. Андыктан модага, шыбагаларга көңүл бурбаңыз. Акылдуу танда.

Микросервистерди сыноо үчүн кайсы китепканаларды колдоно алам?

Бул сиздин стекке көз каранды. Эгер сизде жазгы экосистема орнотулган болсо, анда алHowтын атайын куралдарын колдонуу акылдуулукка жатат . Эгерде JavaEE Arquillian сыяктуу бир нерсе болсо . Жергorктүү өнүгүү же интеграциялык тесттер үчүн Oracle маалымат базасын оңой жана тез түзүүгө жардам берген Docker жана чындап эле жакшы Testcontainers китепканасын карап чыгуу керек . Бүтүндөй HTTP serverлерин жасалма тестирлөө үчүн, Wiremock . Асинхрондук билдирүүлөрдү текшерүү үчүн ActiveMQ же RabbitMQ колдонуп көрүңүз, андан кийин Awaitility DSL аркылуу тесттерди жазыңыз . Мындан тышкары, бардык кадимки куралдарыңыз колдонулат - Junit , TestNG for AssertJ жана Mockito . Бул толук тизме эмес экенин эске алыңыз. Сүйүктүү куралыңызды бул жерден таппасаңыз, аны комментарийлер бөлүмүнө жазыңыз.

Бардык Java микросервистери үчүн журналды кантип иштетүү керек?

Микросервистерге кирүү - бул кызыктуу жана татаал тема. Сиз азыраак же grep буйруктары менен башкара турган бир журнал файлынын ордуна, азыр сизде n журнал файлы бар жана алардын өтө чачыранды болбошун каалайсыз. Каротаждын экосистемасынын өзгөчөлүктөрү бул макалада жакшы сүрөттөлгөн (англис тorнде). Аны окуп чыгууну унутпаңыз жана микросервистердин көз карашынан борборлоштурулган журналга жазуу бөлүмүнө көңүл буруңуз . Практикада сиз ар кандай ыкмаларга туш болосуз: Системалык администратор ар кандай serverлердин лог файлдарын бир журнал файлына чогулткан жана бириктирген белгилүү скрипттерди жазат жана аларды FTP serverлерине жүктөө үчүн коёт. Cat/grep/unig/сорт айкалыштарын параллелдүү SSH сессияларында иштетүү. Amazon AWS дал ушундай кылат жана сиз менеджериңизге кабарлай аласыз. Graylog же ELK Stack (Elasticsearch, Logstash, Kibana) сыяктуу куралды колдонуңуз

Менин микросервистерим бири-бирин кантип табышат?

Ушул убакка чейин биздин микросервистер бири-бирин билет жана тиешелүү IPSти билет деп ойлогонбуз. Статикалык конфигурация жөнүндө сүйлөшөлү. Ошентип, биздин банктык монолит [ip = 192.168.200.1] касиеттер файлында катуу codeдолгон тобокелдик serverи [ip = 192.168.200.2] менен сүйлөшүү керек экенин билет. Бирок, сиз нерселерди динамикалуу кыла аласыз:

• Булутка негизделген конфигурация serverин колдонуңуз, андан бардык микросервистер микросервистерине application.properties файлдарын жайгаштыруунун ордуна конфигурацияларын тартып алышат.
• Кызмат инстанцияларыңыз динамикалык түрдө жайгашкан жерин өзгөртө алгандыктан, кызматтарыңыз кайда жашаарын, алардын IP даректерин жана аларды кантип багыттоо керектигин билген кызматтарды карап чыгуу керек.
• Азыр бардыгы динамикалуу болуп, жетекчини автоматтык түрдө шайлоо сыяктуу жаңы көйгөйлөр пайда болууда: мисалы, эки жолу иштелбеш үчүн тигил же бул тапшырмалардын үстүндө иштеген кожоюн ким? Жетекчи иштебей калганда аны ким алмаштырат? Алмашуу эмненин негизинде ишке ашат?

Жалпысынан алганда, бул микросервис оркестри деп аталат жана бул дагы бир түпсүз тема. Eureka же Zookeeper сыяктуу китепканалар кайсы кызматтар бар экенин көрсөтүү менен бул көйгөйлөрдү "чечүүгө" аракет кылышат. Башка жагынан алганда, алар кошумча татаалдыкты киргизет. ZooKeeperди орноткон адамдан сураңыз.

Java микросервистерин колдонуу менен авторизацияны жана аутентификацияны кантип уюштуруу керек?

Бул тема да өзүнчө окуяга татыктуу. Дагы бир жолу, параметрлер ыңгайлаштырылган коопсуздук алHowтары менен катуу codeдолгон негизги HTTPS аутентификациясынан баштап, өзүнүн авторизация serverи менен Oauth2 орнотуусун иштетүүгө чейин.

Бардык чөйрөлөрүмдүн окшош экенин кантип текшере алам?

Микросервиссиз жайылтуулар үчүн туура болгон нерсе, бирөө менен жайгаштырууларга да тиешелүү. Docker/Testcontainers жана Scripting/Ansible айкалыштырып көрүңүз.

Суроо жок: YAML жөнүндө кыскача

Келгиле, китепканалардан жана ага байланыштуу маселелерден бир азга алыстап, Ямлды тез карап көрөлү. Бул файл форматы "конфигурацияны code катары жазуу" форматы катары де-факто колдонулат. Аны Ansible сыяктуу жөнөкөй куралдар жана Kubernetes сыяктуу гиганттар да колдонушат. YAML чегинүүсүнүн азабын сезүү үчүн жөнөкөй Ansible файлын жазып көрүңүз жана файл күтүлгөндөй иштей электе канча түзөтүшүңүз керек экенин көрүңүз. Бул формат бардык негизги IDE тарабынан колдоого алынганына карабастан! Андан кийин, бул колдонмону окуп бүтүрүү үчүн кайтып келиңиз.

Yaml:
  - is:
    - so
    - great

Бөлүштүрүлгөн транзакциялар жөнүндө эмне айтууга болот? Аткаруучулук сыноо? Башка темалар?

Балким, качандыр бир күнү, колдонмонун кийинки басылмаларында. Азырынча, баары ушул. Биз менен кал!

Микросервистердин концептуалдык маселелери

Javaдагы микросервистердин спецификалык көйгөйлөрүнөн тышкары, башка көйгөйлөр бар, айталы, кандайдыр бир микросервис долбоорунда пайда болгон көйгөйлөр. Алар негизинен уюмга, командага жана башкарууга тиешелүү.

Frontend жана Backend дал келбейт

Frontend жана Backend дал келбеши көптөгөн микросервис долбоорлорунда кеңири таралган көйгөй болуп саналат. Ал эмнени билдирет? Болгону, эски монолиттерде веб-интерфейстерди иштеп чыгуучулар маалыматтарды алуу үчүн белгилүү бир булак болгон. Микросервис долбоорлорунда алдыңкы иштеп чыгуучулар күтүлбөгөн жерден маалыматтарды алуу үчүн n булакка ээ болушат. Элестеткиле, сиз Java'да кандайдыр бир IoT (Internet of Things) микросервис долбоорун түзүп жатасыз. Сиз Европа боюнча геодезиялык машиналарды жана өнөр жай мештерин башкарасыз дейли. Жана бул мештер сизге температуралары жана ушул сыяктуу нерселер менен үзгүлтүксүз жаңыртууларды жөнөтүшөт. Эртеби, кечпи, сиз администратор UIден мештерди тапкыңыз келиши мүмкүн, балким, "меш издөө" микросервистерин колдонуп. Сиздин serverдеги кесиптештериңиз доменге негизделген дизайнды же микросервис мыйзамдарын канчалык катуу колдонгонуна жараша , "меш табуу" микросервиси түрү, модели же жайгашкан жери сыяктуу башка маалыматтарды эмес, мештин ID'лерин гана кайтара алат. Бул үчүн, фронтондук иштеп чыгуучулар биринчи микросервистен алган идентификаторлору менен "мештин маалыматтарын алуу" микросервисинде бир же n кошумча чалууларды (пейджингди ишке ашырууга жараша) жасашы керек. Бул жөнөкөй эле мисал болсо да, чыныгы (!) долбоордон алынганы менен, ал дагы төмөнкү көйгөйдү көрсөтүп турат: супермаркеттер абдан популярдуу болуп калды. Себеби алар менен жашылча, лимонад, тоңдурулган пицца жана даарат кагаз сатып алуу үчүн 10 башка жерге баруунун кажети жок. Анын ордуна бир жерге барасыз. Бул оңой жана тезирээк. Ошол эле фронттук жана микросервис иштеп чыгуучуларга да тиешелүү.

Башкаруу күтүүлөр

Менеджмент азыр (жалпы) долбоор үчүн чексиз сандагы иштеп чыгуучуларды жалдаш керек деген жаңылыш ойдо, анткени иштеп чыгуучулар эми бири-биринен көз карандысыз, ар бири өз микросервисинде иштей алышат. Бир аз гана интеграциялоо иши эң аягында талап кылынат (ишке киргизүүдөн бир аз мурун). Чынында, бул ыкма абдан көйгөйлүү болуп саналат. Кийинки абзацтарда мунун себебин түшүндүрүүгө аракет кылабыз.

"Кичинекей бөлүктөр" "жакшы бөлүктөргө" барабар эмес

20 бөлүккө бөлүнгөн code сөзсүз түрдө бир бүтүн бөлүктөн жогору сапатта болот деп ойлошубуз чоң жаңылыштык болот. Биз сапатты жалаң техникалык көз караштан алсак да, биздин жеке кызматтарыбыз дагы эле колдоого алынбаган codeдун катмарларын басып өтүп, маалымат базасынан колдонуучуну тандоо үчүн 400 күтүү режиминде сурамдарды иштетиши мүмкүн. Дагы бир жолу, биз Саймон Браундун цитатасына кайрылабыз: эгерде сиз монолиттерди туура кура албасаңыз, анда туура микросервистерди куруу кыйынга турат. Микросервис долбоорлорунда каталарга чыдамдуулук жөнүндө сөз кылуу көбүнчө кеч болуп калат. Ошентип, микросервистердин реалдуу долбоорлордо кантип иштээрин көрүү кээде коркунучтуу. Мунун себеби, Java иштеп чыгуучулары каталарга чыдамдуулук, тармактык жана башка тиешелүү темаларды тийиштүү деңгээлде изилдөөгө дайым даяр эмес. "Бөлүмдөрдүн" өздөрү кичине, бирок "техникалык бөлүктөрү" чоңураак. Элестеткиле, сиздин микросервис тобуңуз маалымат базасы тутумуна кирүү үчүн техникалык микросервисти жазууну суранды, мисалы:

@Controller
class LoginController {
    // ...
    @PostMapping("/login")
    public boolean login(String username, String password) {
        User user = userDao.findByUserName(username);
        if (user == null) {
            // обработка варианта с несуществующим пользователем
            return false;
        }
        if (!user.getPassword().equals(hashed(password))) {
            // обработка неверного пароля
            return false;
        }
        // 'Ю-ху, залогинorсь!';
        // установите cookies, делайте, что угодно
        return true;
    }
}

Эми сиздин командаңыз мунун баары өтө жөнөкөй жана кызыксыз экенин чечиши мүмкүн (жана, атүгүл ишкерлерди да ынандырат), логин кызматын жазуунун ордуна, чындап эле пайдалуу UserStateChanged микросервисин эч кандай реалдуу жана реалдуу бизнес талаптары жок жазган жакшы. Жана азыркы учурда кээ бир адамдар Javaга динозавр сыяктуу мамиле кылгандыктан, келгиле, UserStateChanged микросервисибизди модалуу Erlang менен жазалы. Келгиле, бир жерде кызыл-кара дарактарды колдонуп көрөлү, анткени Стив Йегге Google'га кайрылуу үчүн аларды сыртынан бorш керек деп жазган. Интеграция, тейлөө жана жалпы дизайн көз карашынан алганда, бул бир монолиттин ичинде спагетти codeунун катмарларын жазуу сыяктуу эле жаман. Жасалма жана кадимки мисал? Бул чыныгы. Бирок, бул иш жүзүндө болушу мүмкүн.

Азыраак даана - азыраак түшүнүү

Андан кийин табигый түрдө системаны, анын процесстерин жана иш агымдарын түшүнүү жөнүндө суроо туулат, бирок ошол эле учурда сиз иштеп чыгуучу катары обочолонгон микросервисиңизде иштөө үчүн гана жооп бересиз [95: login-101: updateUserProfile]. Бул мурунку абзац менен шайкеш келет, бирок сиздин уюмуңузга, ишенимиңизге жана байланышыңызга жараша, бул микросервис чынжырында кокусунан бузулуп калса, көп баш аламандыкка, ийинин куушуруп, күнөөлөөгө алып келиши мүмкүн. Ал эми болгон окуя үчүн толук жоопкерчorкти ала турган эч ким жок. Жана бул такыр абийирсиздик эмес. Чынында, ар кандай бөлүктөрдү бириктирүү жана долбоордун жалпы картинасында алардын ордун түшүнүү абдан кыйын.

Байланыш жана тейлөө

Байланыш жана тейлөө деңгээли компаниянын көлөмүнө жараша абдан өзгөрүп турат. Бирок, жалпы байланыш ачык көрүнүп турат: канчалык көп болсо, ошончолук көйгөйлүү.

• №47 микросервисти ким башкарат?
• Алар микросервистин жаңы, шайкеш келбеген versionсын орнотуштубу? Бул кайда documentтештирилген?
• Жаңы функцияны талап кылуу үчүн ким менен сүйлөшүшүм керек?
• Бул тилди билген жалгыз адам компаниядан кеткенден кийин, Эрлангдагы микросервисти ким колдойт?
• Биздин бардык микросервис командалары ар кандай программалоо тилдеринде гана эмес, ар кандай убакыт алHowтарында да иштешет! Мунун баарын кантип туура координациялайбыз?

Негизгиси, DevOps сыяктуу эле, чоң, балким, эл аралык компанияда микросервистерге толук кандуу мамиле, бир топ кошумча байланыш көйгөйлөрү менен коштолот. Ал эми компания буга олуттуу даярдануусу керек.

корутундулар

Бул макаланы окугандан кийин, сиз автор микросервистердин жалындуу каршылашы деп ойлошуңуз мүмкүн. Бул таптакыр туура эмес - мен негизинен жаңы технологиялар үчүн жинди жарышта аз адамдар көңүл бурган учурларды баса белгилегенге аракет кылып жатам.

Микросервис же монолит?

Каалаган убакта, каалаган жерде Java микросервистерин колдонуу - бул эң сонун. Экинчиси монолиттеги жүздөгөн жакшы эски Maven модулдарына окшош. Сиздин милдет - туура балансты табуу. Бул өзгөчө жаңы долбоорлорго тиешелүү. Жыйырма булутка даяр микросервистерден баштоонун ордуна, консервативдик, "монолиттик" мамилени колдонууга жана азыраак жакшы Maven модулдарын түзүүгө эч нерсе тоскоолдук кыла алbyte.

Микросервис кошумча татаалдыкты жаратат

Канчалык көп микросервистерге ээ болсоңуз жана сизде канчалык күчтүү DevOps болсо (жок, бир нече Ansible скрипттерин иштетүү же Heroku-га жайгаштыруу эсепке алынbyte!), процессте ошончолук көп көйгөйлөр пайда болорун эсиңизден чыгарбаңыз. Бул колдонмонун Java микросервистери жөнүндө жалпы суроолорго арналган бөлүмүн аягына чейин окуу да өтө түйшүктүү иш. Бул инфраструктуралык көйгөйлөрдүн баарын чечүү жолдорун ишке ашыруу жөнүндө жакшылап ойлонуңуз жана күтүлбөгөн жерден бул бизнес программалоо жөнүндө эмес (эмне үчүн акча төлөйсүз) эмес, тескерисинче, көбүрөөк технологияга көбүрөөк технологияларды орнотуу жөнүндө экенин түшүнөсүз. Шива Прасад Редди өзүнүн блогунда муну эң сонун жыйынтыктады : “Команда убакыттын 70%ын ушул заманбап инфраструктура менен күрөшүп, 30% гана бизнес логикасын аткарууга калганда кандай коркунучтуу экенин билбейсиңер. Шива Прасад Редди

Java микросервистерин түзүү керекпи?

Бул суроого жооп берүү үчүн, мен бул макаланы Google интервьюсуна окшош тизер менен аяктагым келет. Эгер сиз бул суроонун жообун өз тажрыйбаңыздан билсеңиз, анын микросервистерге эч кандай тиешеси жоктой сезилсе да, сиз микросервистерге болгон мамилеге даяр болушуңуз мүмкүн.

Сценарий

Элестетиңиз, сизде эң кичинекей Hetzner арналган serverинде жалгыз иштеген Java монолити бар . Ушул эле нерсе сиздин маалымат базаңыздын serverине да тиешелүү, ал дагы окшош Hetzner машинасында иштейт . Жана ошондой эле сиздин Java монолитиңиз жумуш процесстерин, айталы, колдонуучунун каттоосун башкара алат деп ойлойлу жана сиз ар бир иш процессине жүздөгөн маалыматтар базасынын сурамдарын түзүп жатасыз, бирок акылга сыярлык сан (<10).

Суроо

Сиздин Java монолитиңиз (байланыш бассейниңиз) база serverиңизде канча маалымат базасы туташуусу ачылышы керек? Эмнеге андай? Сиздин оюңузча, сиздин монолитиңиз (болжол менен) масштабда канча активдүү колдонуучу бар?

Жооп

Бул суроолорго жоопуңузду комментарийлер бөлүмүнө калтырыңыз. Мен бардык жоопторду чыдамсыздык менен күтөм. Эми бир чечимге кел. Эгерде сиз аягына чейин окусаңыз, биз сизге абдан ыраазыбыз!