- v1.0.0-latest-prod
Broadleaf has developed a unique technology called Flex Package Composition that is targeted directly at advanced composable commerce. A Flex Package is a deployment configuration and packaging concept that allows multiple Broadleaf microservices to exist in a single JVM runtime under a single Spring instance. The services themselves are designed to maximize the flexibility of deployment options. Broadleaf provides 3 compositions to help illustrate and give an understanding of the various possibilities.
Min - The Highly Coupled Service DeploymentOne extreme would be to deploy all of the microservices together in a single container as shown in the diagram below. This option represents the minimum deployment footprint necessary to support the Broadleaf microservices stack and has the advantage of being a simple and lower hardware cost footprint for some installations.
This type of deployment does not get all of the benefits of microservices such as independent scalability or being able to have each service operate in its own maintenance cycle. Because they share the same spring boot application, services deployed together must be able to operate with the same library dependencies.
Generally, this model is good for local development and for clients with lower volume infrastructures. As it is easy to split services out of this model, this is also a good way to get going quickly with the ability to move services out in an incremental way.
Balanced - The Balanced Service DeploymentThis is the recommended starting composition for most enterprise clients. The services are broken down into 4 primary flex packages: browse, cart, supporting, and processing.
Balanced is unique in that it is designed to leverage read and process replicas. The processing FlexPackage is a "process" replica and contains some duplicates of services from other FlexPackages (e.g. catalog, customer). The purpose of the duplication is to facilitate a separate FlexPackage for long lifecycle write processes (e.g. import and indexing).
|
Note
|
(*) The processing Flex Package has some unique properties wherein some services are only included with input listeners for import and sandboxing transitions ONLY (and will be exempt from servicing typical request traffic). i.e. allowing heavy back office functions to be scaled independently while not impacting customer facing browse flows or vice versa.
|
Granular The Low Coupled Service DeploymentThe other extreme option for deploying microservices is to separate each service into its own deployment as illustrated below. This option allows for each service to be independently scaled and to have its own lifecycle. Some services will be very stable and only upgraded occasionally while others may be under heavy development with more frequent deployments.
The high coupling approach is appropriate for companies new to complex dev-ops and cloud deployments and for companies that do not have complex, high volume sites and is generally good for local development.
For most, the best deployment will be in between these two extremes such as the Balanced configuration. Considerations should be
based on the rate of change of the service, volume of calls to the service, the other systems
involved, and other company architecture standards.
Broadleaf’s starter projects ship with these three example Flex Package compositions. Broadleaf can also provide assistance with the best architecture based on the requirements of a
specific implementation.
It is important to know that each service can have its own database. This could be a separate cloud database per service or a separate schema within a shared cloud database.
Most companies will utilize one (or a few) cloud database with each service configured to a separate schema.
An advantage of the Broadleaf approach is that you can easily move a schema to its own DB or combine schemas into a single DB as you evaluate the usage patterns of your applications.
With some cloud providers, the number of connections required can be very high when each microservice needs its own connection pool. Broadleaf has solved this problem by allowing for services running in the same container that also talk to the same Cloud DB to use the same connection pool in a way that switches the schema between calls.
Broadleaf runs on open source technologies and containers and as such can be run in most cloud infrastructures. Broadleaf can also be run in private data centers for customers that require more control of the infrastructure.
Broadleaf has been deployed in AWS, Azure, Alibaba, and Google Cloud.