{"id":18949987,"url":"https://github.com/salesforce/apollo","last_synced_at":"2025-04-09T23:16:28.544Z","repository":{"id":37359539,"uuid":"206137428","full_name":"salesforce/apollo","owner":"salesforce","description":"An experimental multi-tenant distributed system platform","archived":false,"fork":false,"pushed_at":"2024-11-12T19:58:25.000Z","size":36417,"stargazers_count":57,"open_issues_count":8,"forks_count":13,"subscribers_count":10,"default_branch":"master","last_synced_at":"2025-04-09T23:16:21.016Z","etag":null,"topics":["consensus","dag","distributed-database","gossip-protocol","secure-membership"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/salesforce.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-09-03T17:45:04.000Z","updated_at":"2025-04-04T04:39:16.000Z","dependencies_parsed_at":"2024-01-05T02:41:55.805Z","dependency_job_id":"cb057bf4-1161-4f92-8659-9821ca2c00cd","html_url":"https://github.com/salesforce/apollo","commit_stats":{"total_commits":129,"total_committers":6,"mean_commits":21.5,"dds":0.2325581395348837,"last_synced_commit":"07a0fb8855d600d189b6de79393205ee632a38da"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforce%2Fapollo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforce%2Fapollo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforce%2Fapollo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforce%2Fapollo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/salesforce","download_url":"https://codeload.github.com/salesforce/apollo/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248125593,"owners_count":21051771,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["consensus","dag","distributed-database","gossip-protocol","secure-membership"],"created_at":"2024-11-08T13:20:07.147Z","updated_at":"2025-04-09T23:16:28.523Z","avatar_url":"https://github.com/salesforce.png","language":"Java","funding_links":[],"categories":["数据库"],"sub_categories":[],"readme":"# Apollo Delphinius\n\nThe Apollo Delphinius project is an experimental multi-tenant, distributed system platform. Apollo provides a secure\ncommunications overlay using Fireflies. The consensus layer is supplied by an asynchronous bft consensus protocol. The\nsql state interface is via a JDBC connection over replicated SQL state machines, supported by check pointed CHOAM linear\nlogs. Decentralized identity and key management are provided as a foundational service and integrated into the MTLS grpc\ncommunication.\n\nThe target service goal is a multi-tenant secrets manager that provides a wide area replicated, low latency\nservice for managing identity, key management, access control and verifiable credentials.\n\n## Build Status\n\n![Build Status](https://github.com/salesforce/apollo/actions/workflows/maven.yml/badge.svg)\n\nThe Java Maven CI is now integrated, and given how weak these CI daemons are, this should guarantee reproducible clean\nbuilds from the command line maven.\n\n## Not A Coin Platform™\n\nApollo is not designed for coins, rather it is a distributed multi-tenant database. While the systems\nand mechanisms of Apollo can be used for coins/etc, the design goals are much different. Thus, no coins for you.\n\n## Some Features\n\n* Multi tenant isolation enclaves using GraalVM Isolates\n* Self-contained cryptography module — Self describing Digests, Signatures and Identifiers, solid Bloom Filters,\n  windows, etc\n* Decentralized Identifier-based foundation and key management infrastructure, based on\n  the [Key Event Receipt Infrastructure](https://github.com/decentralized-identity/keri) (KERI)\n* Secure and trusted attestation, identity bootstrapping and secrets provisioning\n* MTLS network communication — KERI for MTLS certificate authentication. Local communication simulation for simplified\n  multi-node simulation for single process (IDE) testing\n* Multi instance GRPC service routing - Context keyed services and routing framework\n* Byzantine intrusion tolerant secure membership and communications overlay providing virtually synchronous, stable\n  membership views.\n* Efficient and easy to reuse communication patterns for Fireflies ring style gossiping on membership contexts\n* Reliable Broadcast — garbage collected, context routed reliable broadcast\n* Efficient atomic broadcast in asynchronous networks with byzantine nodes - Consensus\n* Dynamic, committee-based, causal ordering service producing linear logs - Replicated State Machines\n* JDBC accessible, SQL store backed, materialized views maintained by an SQL state machine. Supports DDL, DML, stored\n  procedures, functions and triggers.\n* Google Zanzibar like functionality providing Relation Based Access Control hosted on SQL state machines.\n\n## Requirements\n\nApollo requires JDK 22+ and [Maven](https://maven.apache.org/) 3.9.3 and above\n\n### Install Maven\n\nThe build includes  _mvnw_, and thus there is no need to install Maven. Simply use ./mvnw for all your Maven invocation\nneeds.\n\nSee [Installing Apache Maven](https://maven.apache.org/install.html) if you prefer to install Maven.\n\n### Install GraalVM (Optional)\n\nApollo optionally requires the GraalVM 22.3.1+ for leveraging Isolates and other fantastic features of the GraalVM. To\ninstall the GraalVM, see the [Getting Started Guide](https://www.graalvm.org/latest/docs/getting-started/). For Mac and\nApple Silicon, use the [Homebrew Tap for GraalVM](https://github.com/graalvm/homebrew-tap).\n\n## Building Apollo\n\n**Important**: To provide deterministic SQL execution, Apollo requires an installation step that need only be done once.\nIf you are building Apollo for the first time, you  __must__  cd to the root directory of the repository and then:\n\n    ./mvnw clean install -Ppre -DskipTests\n\nThis will perform a full build including the deterministic SQL execution module. After this is complete, you do not\nneed to do this again. You can build Apollo normally without the deterministic SQL module and to do so cd to the root\ndirectory of the repository and then:\n\n    ./mvnw clean install\n\nNote that the  _install_  maven goal is **required**, as this installs the modules in your local repository for use by\ndependent modules within the rest of the build. You must have invoked maven on the Apollo project root with the \"\ninstall\"\ngoal at least once, to correctly build any arbitrary submodule.\n\nYou can use the \"--also-make-dependents\" argument for maven \"-amd\" if you want to build a particular module\nwithout performing the full build.\n\n### Building Apollo Isolate Enclaves\n\nGeneration of Apollo shard enclave shared libraries is delegated to the *isolate*  profile:\n\n    ./mvnw clean install -Pisolates\n\nThis will add the *[isolates](isolates/README.md)* modules to the build.\n\n### Platform Specific Domain Socket Support\n\nPlatform-specific code for supporting Unix Domain Socket in GRPC Netty is segregated into two different modules:\n*[domain-epoll](domain-epoll)* and *[domain-kqueue](domain-kqueue)*. These modules are added via platform-specific\nprofiles that are activated for the platform the build is running on.\n\n## Modules\n\nApollo is modularized largely for subsystem isolation and reuse. Each module is a Maven module\nunder the source root and contains a README.md documenting the module.\n\n* [CHOAM](choam/README.md) - Committee maintenance of replicated state machines\n* [Delphinius](delphinius/README.md) - Bare bones Google Zanzibar clone\n* [Domain-EPoll](domain-epoll) - linux support for Netty domain sockets\n* [Domain-KQueue](domain-epoll) - mac osx support for Netty domain sockets\n* [Domain-Sockets](domain-sockets) - unifying abstraction for the different OS domain sockets\n* [Ethereal](ethereal/README.md) - Aleph asynchronous BFT atomic broadcast (consensus block production)\n* [Fireflies](fireflies/README.md) - Byzantine intrusion tolerant, virtually synchronous membership service and secure\n  communications overlay\n* [Deterministic H2](h2-deterministic) - Deterministic H2 SQL Database\n* [Deterministic Liquibase](liquibase-deterministic) - Deterministic Liquibase\n* [Gorgoneion](gorgoneion/README.md) - Identity bootstrapping\n* [Gorgoneion Client](gorgoneion-client/README.md) - Identity bootstrap client\n* [Isolates](isolates/README.md) - GraalVM shared library construction of Apollo subdomain enclaves.\n* [Isolate Functional Testing](isolate-ftesting/README.md) - Functional testing of Apollo domain enclaves.\n* [Memberships](memberships/README.md) - Fundamental membership and Context model. Local and MTLS GRPC _Routers_. Ring\n  communication and gossip patterns.\n* [Model](model/README.md) - Replicated domains. Process and multi-tenant sharding domains and enclaves.\n* [Protocols](protocols/README.md) - GRPC MTLS service fundamentals, Netflix GRPC and other rate limiters.\n* [Schemas](schemas/README.md) - Liquibase SQL definitions for other modules\n* [Sql-State](sql-state/README.md) - Replicated SQL state machines running on CHOAM linear logs. JDBC interface.\n* [Stereotomy](stereotomy/README.md) - Key Event Receipt Infrastructure. KEL, KERL and other fundamental identity, key\n  and trust management\n* [Stereotomy Services](stereotomy-services) - GRPC services and protobuf interfaces for KERI services\n* [Thoth](thoth/README.md) - Decentralized Stereotomy. Distributed hash table storage, protocols and API for managing\n  KERI decentralized identity\n* [Tron](tron/README.md) - Compact, sophisticated Finite State Machine model using Java Enums.\n* [Cryptography](cryptography/README.md) - Base cryptography primitives. Bloom filters (of several varieties). Some\n  general utility stuff.\n\n## Protobuf and GRPC\n\nApollo uses Protobuf for all serializations and GRPC for all interprocess communication. This implies code generation.\nNot something I adore, but not much choice in the matter. GRPC/Proto generation also appears not to play well with the\nEclipse IDE Maven integration. To aleviate this,  _all_  grpc/proto generation occurs in one module, the aptly named\n_grpc_  module.\n\n## JOOQ\n\nApollo makes use of [JOOQ](https://www.jooq.org) as an SQL DSL for Java. This also implies code generation and, again,\nnot something I adore. Unlike GRPC, the JOOQ code generation plays very nicely with the Eclipse IDE's Maven integration,\nso JOOQ code generation is included in the module that defines it.\n\n## WIP\n\nNote that Apollo Delphinius is still a  _work_   _in_   _progress_ . There is not yet an official release. Thus, it\nis by no means a full-featured, hardened distributed systems platform.\n\n## Requirements\n\nApollo is a pure Java application The build system is Maven, and requires Maven 3.9.3+. The Maven enforcer plugin\nenforces dependency convergence, and Apollo is built using Java 22.\n\nApollo is a [multimodule Maven project](https://maven.apache.org/guides/mini/guide-multiple-modules.html). This means\nthat the various modules of Apollo are built and versioned as a whole, rather than being separated out into individual\nrepositories. This also means that modules refer to other modules within the project as dependencies, and consequently\nmust be built in the correct order. Note that Maven does this by default, so there should be no issues. However, it does\nmean that one can't simply cd into a module and build it without building its dependencies first. If you feel you must\ndo so, please make sure to include the \"install\" goal and please make sure you add the \"--also-make-dependents\" or \"\n--amd\" parameter to your maven invocation.\n\n## Code Generation In Apollo\n\nApollo requires code generation as part of the build. This is performed in the Maven \"generate-sources\" phase of the\nbuild. Consequently, this build phase *must* be run at least once in order to generate the java sources required by the\nrest of the build.\n\nThe current code generators used in Apollo are GRPC/Proto and JOOQ. GRPC is for the various serializable forms and\nnetwork protocols used by Apollo. The JOOQ code generation is for the JOOQ SQL functionality.\n\nGRPC/Protoc code generation only occurs in the _grpc_  module and is output into the  _grpc/target/generated-sources_\ndirectory. For GRPC/Proto, there are 2 directory roots:  _grpc/target/generated-sources/protobuf/grpc-java_  and\n_grpc/target/generated-sources/protobuf/java_ . For JOOQ, the root directory is  _(module dir)\n/target/generated-sources/jooq_ .\n\nAgain, I stress that because these generated source directories are under the \"(module dir)/target\" directory, they are\nremoved during the \"clean\" phase of Maven and consequently must be regenerated to compile the rest of the\nbuild.\n\nNote that adding these generated source directories to the compiler path is automatically taken care of in the Maven\n*pom.xml* in the \"build-helper\" plugin.\n\n## IDE Integration\n\n**This is Important!**\nApollo contains one module that create a shaded version of standard libraries. This module **must** be built (\ninstalled), but only needs to be built once in order to install the resulting jar into your local maven repository. This\nis performed as part of the top level pom's  _pre_  profile. As mentioned previously, this profile must be executed at\nleast once before the full build. Note, however, Eclipse and IntellJ **do not understand this transformation** and\nthus will not be able to import this module without errors and messing up the rest of the code that depends on the\ntransformation. What this means is that the IDE thinks the module is fine and doesn't notice there has been package\nrewriting to avoid conflicts with existing libraries. What this means is that you *must* exclude this module in your IDE\nenvironment. This module will not be imported unless you explicitly do so, so please do not do so. If you really think\nyou need to be working on it, then you probably understand all this. But if you are simply trying to get Apollo into\nyour IDE, importing these modules is gonna ruin your day.\n\n### Module to exclude\n\nThe module to exclude is:\n\n* h2-deterministic\n\nAgain, I stress that you must **NOT** include this in the import of Apollo into your IDE. You'll be scratching your head\nand yelling at me about uncompilable code, and I will simply, calmly point you to this part of the readme file.\n\nThis module must be built, so please run the following once from the top level of the repository\n\n    mvn clean install -Ppre -DskipTests\n\nFrom the command line before attempting to load the remaining Apollo modules into your IDE. Again, this only needs to be\ndone once as this will be installed in your local Maven repository, and you won't have to do it again. Rebuilding this\nmodule will have no adverse effect on the rest of the build.\n\n### Eclipse M2E issues with ${os.detected.classifier}\n\nThis is a known weirdness with Eclipse M2E with\nthe [os-maven-plugin build extension](https://github.com/trustin/os-maven-plugin). I've been fine with this, but ran\ninto another project that Eclipse just kept refusing to resolve. I solved this by downloading\nthe [supplied maven plugin](https://repo1.maven.org/maven2/kr/motd/maven/os-maven-plugin/1.7.0/os-maven-plugin-1.7.0.jar)\nand adding this to the **\u003cECLIPSE_HOME\u003e/dropins** directory. This works because the plugin is also an Eclipse plugin,\nwhich is nice.\n\n### Your IDE and Maven code generation\n\nDue to the code generation requirements (really, I can't do jack about them, so complaining is silly), the generation\nphase can occasionally cause interesting issues with your IDE when you import Apollo. I work with Eclipse, and things\nare relatively fine with the current releases. However, there are sometimes synchronization issues in Eclipse Maven\nintegration that invalidates the generated code and that may require an additional *generate-sources* pass. Apollo is a\nmultimodule project and be sure you're leaving time for the asynchronous build process to complete.\n\nI have no idea about IntellJ or Visual Code, so you're on your own there.\n\nWhat I  _strongly_  recommend is first building from the command line with **-DskipTests** - i.e **mvn clean install\n-DskipTests**. This will ensure all dependencies are downloaded and all the code generation is complete. Further, if you\nhaven't updated from this repo in a while, don't try to be clever. Delete all the modules from this project from your\nide, build/test from the command line and _then_ reimport things. Don't ask for trouble, I always say.\n\nAfter you do this, you shouldn't have any issue *if* your IDE Maven integration knows about and takes care of using the\nbuild-helper plugin to manage compilation directories for the module in the IDE. However…\n\nMyself, I find that I have to first select the top level Apollo.app module, and then **Menu -\u003e Run As -\u003e Maven generate\nsources** (or the equivalent in your IDE). This *should* generate all the sources required for every submodule, so...\n\nFeel free to generate issues and such, and I will look into it as I do want this to be flawless and a good experience. I\nknow that's impossible, but it undoubtedly can be made better, and PRs are a thing.\n\nNote that also, for inexplicable reasons, Eclipse Maven will determine it needs to invalidate the _grpc_ generated code\nand will thus need to be regenerated. I'm trying to figure out the heck is going on, but when this happens, please\nsimply\nregenerate by selecting the _grpc_ module and performing: Menu -\u003e Run As -\u003e Maven generate sources (or the equivalent in\nyour IDE).\n\n## Metrics\n\nApollo uses Dropwizard Metrics, and these are available for Fireflies, Reliable Broadcast, Ethereal and CHOAM.\n\n## Testing\n\nBy default, the build uses a reduced number of simulated clients for testing. To enable the larger test suite, use the\nsystem property \"large_tests\". For example\n\n    mvn clean install -Dlarge_tests=true\n\nThis requires a decent amount of resources, using two orders of magnitude more simulated clients in the tests, with\nlonger serial transaction chains per transactioneer client. This runs fine on my Apple M1max, but this is a beefy\nmachine. YMMV.\n\n## Current Status\n\nCurrently, the system is in development. Fundamental identity and digest/signature/pubKey encodings have been\nintegrated.\nApollo is using Aleph-BFT for consensus, in the form of the Ethereal module. CHOAM has now replaced Consortium, and the\nSQL replicated state machine now uses CHOAM for its linear log and transaction model.\n\nMulti-tenant shards are in place and apparently working. This integrates Stereotomy and Delphinius using CHOAM in\na Domain model. E2E testing of the ReBAC Delphinius service is finished and working. Full integration of ProcessDomains\nusing Fireflie and discovery - bootstrap to Delphinius Oracle ReBAC E2E testing.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsalesforce%2Fapollo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsalesforce%2Fapollo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsalesforce%2Fapollo/lists"}