Google Git
Sign in
apache / servicecomb-kie / f3527b9c2ace866fac2553a314e38eeb6b109d75
commitf3527b9c2ace866fac2553a314e38eeb6b109d75[log] [tgz]
authorlittle-cui <sure_0757@qq.com>Tue Aug 24 18:28:39 2021 +0800
committerGitHub <noreply@github.com>Tue Aug 24 18:28:39 2021 +0800
tree3ddb8bf9d4abe833644e53f0239c90cb37186451
parent76ed881f5c38d106a4fda76477742a5f71a7973e [diff]
Fix: Can not page the kvs (#211)
4 files changed
tree: 3ddb8bf9d4abe833644e53f0239c90cb37186451
  1. .github/
  2. build/
  3. cmd/
  4. deployments/
  5. docs/
  6. examples/
  7. licenses/
  8. pkg/
  9. scripts/
  10. server/
  11. test/
  12. .gitignore
  13. go.mod
  14. go.sum
  15. LICENSE
  16. NOTICE
  17. proxy.sh
  18. README.md
README.md

Apache-ServiceComb-Kie

Build Status License Coverage Status A service for configuration management in distributed system.

Conceptions

Key

Key could indicate a configuration like “timeout”, then the value could be “3s” or indicates a file name “app.properties”, then the value could be content of app.properties

Labels

Each key could has labels. labels indicates a unique key. A key “log_level” with labels “env=production” may saves the value “INFO” for all application log level in production environment. A key “log_level” with labels “env=production, component=payment” may saves the value “DEBUG” for payment service in production environment.

It means all payment service print debug log, but for other service print info log.

So you can control your application runtime behaviors by setting different labels to a key.

Why use kie

kie is a highly flexible config server. Nowadays, an operation team is facing different “x-centralized” system. For example a classic application-centralized system. A operator wants to change config based on application name and version, then the label could be “app,version” for locating a app‘s configurations. Meanwhile some teams manage app in a data center, each application instance will be deployed in a VM machine. then label could be “farm,role,server,component” to locate a app’s configurations. kie fit different senario for configuration management which benifit from label design.

Components

It includes 1 components

  • server: rest api service to manage kv

Features

  • kv management: you can manage config item by key and label
  • kv revision mangement: you can mange all kv change history
  • kv change event: use long polling to watch kv changes, highly decreased network cost
  • polling detail track: if any client poll config from server, the detail will be tracked

Quick Start

Run locally with Docker compose

git clone git@github.com:apache/servicecomb-kie.git
cd servicecomb-kie/deployments/docker
sudo docker-compose up

It will launch 3 components

Development

To see how to build a local dev environment, check here

Build

This will build your own service image and binary in local

cd build
export VERSION=0.0.1 #optional, it is latest by default
./build_docker.sh

This will generate a “servicecomb-kie-0.0.1-linux-amd64.tar” in “release” folder, and a docker image “servicecomb/kie:0.0.1”

API Doc

After you launch kie server, you can browse API doc in http://127.0.0.1:30110/apidocs.json, copy this doc to http://editor.swagger.io/

Documentations

https://kie.readthedocs.io/en/latest/

or follow here to generate it in local

Clients

Contact

Bugs: issues

Contributing

See Contribution guide for details on submitting patches and the contribution workflow.

Reporting Issues

See reporting bugs for details about reporting any issues.