[Proposal] A lightweight version of Apollo

ogsagwnx  于 4个月前  发布在  其他
关注(0)|答案(6)|浏览(124)

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.

ncecgwcz

ncecgwcz1#

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

2ekbmq32

2ekbmq322#

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

zpjtge22

zpjtge223#

  1. Support in-memory database

This can only be used in quick start mode?

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

dfuffjeb

dfuffjeb4#

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.

uinbv5nw

uinbv5nw5#

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

kfgdxczn

kfgdxczn6#

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.

相关问题