search

apolloconfig / apollo

Apollo is a reliable configuration management system suitable for microservice configuration management scenarios.
https://www.apolloconfig.com
Apache License 2.0
29.16k stars 10.2k forks source link

[Proposal] A lightweight version of Apollo #4729

Open nobodyiam opened 1 year ago

nobodyiam commented 1 year ago

Apollo is designed based on the microservice pattern. As shown in the diagram below, it consists of several logical components:

  1. Portal
  2. Config Service
  3. Admin Service
  4. Eureka(embedded in config service)
  5. PortalDB and ConfigDB

Architecture Module

This architecture provides very good scalability for medium and large use cases. However, it brings resource cost and operational burden, which is not friendly for small use cases.

Therefore, I think it's better to reduce the architecture complexity and provide a lightweight verision of Apollo.

Below are some potential areas that might help.

  1. Package the portal, config service and admin service into one assembly The idea is to make this assembly configurable, e.g. it can run as an all-in-one mode which serves the role of portal, config service and admin service together. Or it could also run as a standalone role, e.g. config service. With this feature, small team or quick start scenario could use the all-in-one mode to reduce resource comsuption and operational burden. But large company could still keep the distributed capability to maintain scalability. Currently apollo-assembly is used to run the config service and admin service together, so it could be used as a baseline to support portal too.

  2. Support in-memory database Mysql is a simple and easy to use database, however, it still adds some burden for quick start scenarios. I think we could add official support for in-memory database so that users can simple download and run the assembly with no extra cost. Currently the h2 database is used in integration test scenarios, which might be a good start.

  3. Use database as the default service discovery Eureka is now the default service discovery. However, since some users are not familiar with its replication mechanism, it's difficult for them to configure it properly. As 2.1.0 introduced the database-discovery feature, which is simple and easy to understand, so I think we could use it as the default service discovery instead.

Since this proposal may bring major architectural changes to Apollo, I think we could keep this discussion open for a while to receive more suggestions and ideas.

shoothzj commented 1 year ago

Proposal1 looks great! Actually, there are many scenarios one assembly is enough

kezhenxu94 commented 1 year ago

Sounds good to me. I’m willing to help this if needed.

lepdou commented 1 year ago
  1. Support in-memory database

This can only be used in quick start mode?

1&2 I think can be used in production environment.

zouyx commented 1 year ago

I think 1&3 are good ideas. But i am not sure if proposal 2 can be used in production. And i will help this if needed.

kezhenxu94 commented 1 year ago

I assume in-memory database are obviously always for demo and not production, no user wants to lose their data when restart the service.

nobodyiam commented 1 year ago

Support in-memory database

This should only be enabled in quick-start scenarios, we could document this and make sure users are aware of this.