[Proposal] A lightweight version of Apollo

[nobodyiam]

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

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.

[hezhangjian]

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

[kezhenxu94]

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

[lepdou]

2. Support in-memory database

This can only be used in quick start mode?

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

[zouyx]

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]

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]

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.