Anatomy of a microservice, could this be best practice? Where as anything on a local path is on a drive, and anything not having local in path is in memory.

ReadMe.md

Anatomy of a microservice

A best practice?

Depending on the size of your project this may be a partial listing

$ exa -T /opt
/opt
└── local
   └── BFF
      └── orderAndroid
      └── orderComponentOptimized
      └── orderHTML
      └── orderiPadOS
      └── orderiPhablet
      └── orderNCursesThinClient
      └── productAndroid
      └── productComponentOptimized
      └── productHTML
      └── productiPadOS
      └── productiPhablet
      └── productNCursesThinClient
      └── .
      └── .
      └── .
   └── sameServicesDeployedElsewhere
   └── generalpurposeRESTAPI
   └── GraphQL

Where the order folders in BFF may have the same API, what each delivers may differ in format and content. Not to mention sequence, and async / sync. And sameServicesDeployedElsewhere will return a JSON / ION / BSON / XML object with URLs sorted by ping.

A file layout for a deployed binary

A pseudo listing below, mymicroservice is not a real path, but a way to say the files involved in mymicroservice

$ exa -T mymicroservice
/opt
└── local
   └── mymicroservice
      ├── bin
      |  └── mymicroservice
      └── var
         └── archive
         └── log
            └── mymicroservice.log
/tmp
└── mymicroservice

or as pseudo find

$ find mymicroservice
/opt/local/mymicroservice
/opt/local/mymicroservice/bin
/opt/local/mymicroservice/bin/mymicroservice        # The binary
/opt/local/mymicroservice/var
/opt/local/mymicroservice/var/archive               # For serving static files, such as SEO optimizable static HTML pages.
/opt/local/mymicroservice/var/log
/opt/local/mymicroservice/var/log/mymicroservice.log # The log, written for elasticsearch file beat
/tmp/mymicroservice                                  # The unix domain socket for mymicroservice

Of course this will require some benchmarking, however the memory foot print of using a unix domain socket should be significantly smaller than using localhost as this approach is more like a pipe than a network driver. Then again otool -tv /opt/local/mymicroservice/bin/mymicroservice --unixdomainsocket /tmp/mymicroservice | wc -l vs otool -tv /opt/local/mymicroservice/bin/mymicroservice | wc -l will always give a good indicator. We will also have to find the actual memory footprint of the microservice while running.

Typically there will be 4 actual NICs on the box where the hypervisor resides the use cases for the NICs may be versatile.

eno1 WAN client access
eno2 LAN client access operations
eno3 LAN client access batch jobs for maintenance( such as acual deletes, ) backup
eno4 LAN misc

How will these 3 NICs compete for the attention of our microservice?

mymicroserviceRoute.nginx.conf

# "Mounting" mymicroservice as a subroute of the main domain
server {
#  listen domain.tld;
  listen 0.0.0.0;

  location /api/v1/accounts {
    proxy_pass              http://unix:/var/run/keycloakaccount:/;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }

location /api/v1/login {
    proxy_pass              http://unix:/var/run/tld.domain.login:/;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  location /api/v1/admin {
    proxy_pass              http://unix:/var/run/tld.domain.admin:/;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  location /api/v1/product {
    proxy_pass              http://unix:/var/run/tld.domain.product:/;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  location /api/v1/order {
    proxy_pass              http://unix:/var/run/tld.domain.order:/;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }

  location /api/v1/account {
    proxy_pass              http://unix:/var/run/tld.domain.account:/;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}