
Fescar: High-performance, Java-based, OSS distributed transaction solution - axiomdata316
https://github.com/alibaba/fescar
======
omeze
This is cool, but to what extent is the DB-per-Service pattern actually used,
or desirable? The alternative of sharing a DB across many services is simpler
because you still just rely on transactions in you RDBMS. I get that at some
point youll have to shard or go to a multi master setup if thats supported to
scale. Im wondering how many companies find themselves in this situation and
have chosen a datastore that doesnt support multimaster? Or am I missing some
other use case? The wiki links to “supported databases” also doesn’t work...
and I dont get what “high performance” means, is there a blog post or
benchmark for any reference points?

~~~
kronin
Db-per-service provides many benefits, albeit with some drawbacks. If you are
going to adopt microservices, you've already had to accept most of the
drawbacks. Trying to mitigate those drawbacks by consolidating will end up
losing much of the benefits of going to a microservice topology. Sagas or
compensating transactions are a way to answer this concern without the
complexity of a transaction manager.

If each service owns it's datastore, each service can choose the type of
datastore that best fits it's use-case.

Each service can be owned and operated independently. Patches, upgrades,
schema migrations, etc.

Each services' datastore can be scaled, backed up, restored, encrypted, etc
independently all depending on the requirements, scale needs, compliance
concerns, etc of a given service.

A badly behaving service can (mostly) not impact other services, where if they
all shared a single database a single service could theoretically starve other
services.

Yes, the distributed transaction problem is a drawback, but that can be
partially mitigated through better definition of each service's bounded
context.

~~~
ris
I think each of your stated benefits ought to be prefixed with "In a perfect
world...". In the real world people _don 't_ make perfect decisions about
things, and even where they do, requirements often change. _Particularly_ the
core decision about where the borders between the services lie and what
service is responsible for what. Re-architecting a complex microservice
architecture is such an undertaking that instead people will often just live
for years with an absurdly mis-shapen design, still having to live with the
pain that re-appears any time they need to e.g. make synchronized changes to
multiple services.

------
latchkey
The top of the readme starts off with a nice simple diagram of a working
architecture (traditional monolithic) and as you read further, it balloons
into this project + a super complicated set of diagrams with multiple moving
pieces.

