rest - How do micro services in Cloud Foundry communicate? -


i'm newbie in cloud foundry. in following reference application provided predix (https://www.predix.io/resources/tutorials/tutorial-details.html?tutorial_id=1473&tag=1610&journey=connect%20devices%20using%20the%20reference%20app&resources=1592,1473,1600), application consisted of several modules , each module implemented micro service.

my question is, how these micro services talk each other? understand must using sort of rest calls problem is:

  1. service registry: have services a, b, c. how these components 'discover' rest urls of other components? component url known after service pushed cloud foundry.

  2. how cloud foundry controls components dependency during service startup , service shutdown? cannot start until b started. b needs shutdown if shutdown.

the ref-app 'application' consists of several 'apps' , predix 'services'. app bound service via entry in manifest.yml. thus, gets service endpoint , other important configuration information via binding. when app bound service, 'cf env ' command returns needed info.

there might still service endpoint info in property file, that's refactored out on time.

the individual apps of ref-app application put in separate microservices, since used components of other applications. hence, microservices approach. if there startup dependencies across apps, ci/cd pipeline pushes apps cloud need manage these dependencies. dependencies in ref-app obvious ones, read-on.

while it's true coupling of microservices not in design. there obvious reasons might happen. language , function. if have "back-end" microservice written in java used "front-end" ui microservice written in javascript on nodejs these pushed 2 separate apps. theoretically ui won't work without back-end, there plan make happen canned json. still there logical coupling there.

the nice things microservices might need scale differently , cloud foundry makes quite easy 'cf scale' command. might used multiple other microservices, hence creating new scale requirements. so, thinking needs scale , release cycle of functionality helps in deciding comprises microservice.

as ordering, example, google maps api might required application said should launched first , application second. in reality, application should take in account maps api might down. goal should app behaves when dependent microservice not available.

the 'apps' of 'application' know each due name , url cloud gives it. there many copies of reference app running in various clouds , spaces. prefaced things dev or qa or integration, etc. dev front end talking qa back-end microservice, sure, it's url.

in addition aforementioned, etcd (which haven't tried yet), can create cups service 'definition'. set of key/value pairs. can tie space (dev/qa/stage/prod) , bind them via manifest. way props environment.


Comments

Popular posts from this blog

PySide and Qt Properties: Connecting signals from Python to QML -

c# - DevExpress.Wpf.Grid.InfiniteGridSizeException was unhandled -

scala - 'wrong top statement declaration' when using slick in IntelliJ -