|
|
|
# Experimental installation for BYOD
|
|
|
|
|
|
|
|
## Key Experiments
|
|
|
|
* [Azure blob storage](#azure-blob-storage)
|
|
|
|
* [Microservice on goMenu](#microservice-on-gomenu)
|
|
|
|
* [Symlink](#symlink)
|
|
|
|
* [X-Request-ID](#x-request-id)
|
|
|
|
|
|
|
|
### Azure blob storage
|
|
|
|
Main usages
|
|
|
|
* Host the static files for the cloud BYOD ordering.
|
|
|
|
* Synchronize the static files to all shop servers which reduce the time of manual remote update.
|
|
|
|
* Upload the converted menu json to blob for cloud BYOD ordering.
|
|
|
|
|
|
|
|
I used [AzCopy](https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10) to handle the upload and download task. I wrote some batch commands and deployed them to all KABU shops. You can reach me or just remote to any KABU shop if you are interested in the advantage of updating static files without remoting a high number of shops.
|
|
|
|
|
|
|
|
### Microservice on goMenu
|
|
|
|
|
|
|
|
Due to a good experience in modulization for UC RARe. I revamped the goMenu server to modulized goMenu-service and call-service. And added BYOD, BYOD-table-service, and print-service for the goOrder features. I planned to integrate these versions of goMenu-service with RARe. I hope it can break the wasting of RARe-vs-KABU in the past years.
|
|
|
|
|
|
|
|
### Symlink
|
|
|
|
I found a useful method called `symlink` which suite for our deployment which needs to sharing some static files like config, images, etc between serval program. You can take a look at this [guide](/guides/folder-structure-for-deployments) and the [list](symlink-static-files-list).
|
|
|
|
|
|
|
|
|
|
|
|
### X-Request-ID
|
|
|
|
To add ablitity for tracing the same HTTP request through log entries.
|
|
|
|
|
|
|
|
What the problem in the past? Usually your logs look something like this:
|
|
|
|
```
|
|
|
|
[07/Nov/2018:15:48:11 +0000] User sign-up: starting request validation
|
|
|
|
[07/Nov/2018:15:48:11 +0000] User sign-up: starting request validation
|
|
|
|
[07/Nov/2018:15:48:12 +0000] User sign-up: request validation success
|
|
|
|
[07/Nov/2018:15:48:13 +0000] User sign-up: request validation failed. Reason:
|
|
|
|
...
|
|
|
|
```
|
|
|
|
Here, log entries are mixed up and there is no way to determine which of them belong to the same request. While you would probably prefer to see something like this:
|
|
|
|
```
|
|
|
|
[07/Nov/2018:15:48:11 +0000] [rid:550e8400-e29b-41d4-a716-446655440000] User sign-up: starting request validation
|
|
|
|
[07/Nov/2018:15:48:11 +0000] [rid:340b4357-c11d-31d4-b439-329584783999] User sign-up: starting request validation
|
|
|
|
[07/Nov/2018:15:48:12 +0000] [rid:550e8400-e29b-41d4-a716-446655440000] User sign-up: request validation success
|
|
|
|
[07/Nov/2018:15:48:13 +0000] [rid:340b4357-c11d-31d4-b439-329584783999] User sign-up: request validation failed. Reason:
|
|
|
|
...
|
|
|
|
```
|
|
|
|
Notice the `[rid:*]` part that contains request identifiers here. These identifiers will allow you to filter log entries that belong to the same request. Moreover, if your application is composed of microservices communicating with each other over HTTP, request identifiers may be sent in an HTTP header and used for tracing request chains across logs generated by all microservices on the chain.
|
|
|
|
|
|
|
|
## What's next?
|
|
|
|
Centralized logging and monitoring with open-source [ELK stack](https://www.elastic.co/elastic-stack). |
|
|
\ No newline at end of file |
