Please enable JavaScript.
Coggle requires JavaScript to display documents.
Microservices. Foundations. (Features (Every call served via REST (Each…
Microservices. Foundations.
Features
Decomposition
System Decomposition
Every call served via REST
Each team can create service in an appropriate language
Each service can call any other service
Each service has to provide API
Any programming platforms
Salability
Distribution
Drawbacks
Complexity
A lot of components to manage
Deployment complexity
Distribution tax
A lot of network communications
Each call is remote, so it can become a problem is there is a long chain of calls, since we receive tax at each remote call
Circular calls
Should introduce circuit breaker
Introduce strong timeouts
Global distribution of all service offerings
Scaling service under load
Reduction of reliability
Collaboration
How small is 'small'?
It's not about size, it's about operations
Little or none cross-domain operations
Operates one set of related functions
Each service has to be heavily documented
Bounded context
Investigate working system
Determine the domains
Focus on boundaries of this domains
Break services accordingly
Transactional Boundaries
Can't eliminate transactions completely
If transaction is inevitable, then we wrap up a service around this transaction
No distributed transactions
We can't use ANY ACID transactions at all
Only eventual consistency (BASE)
New ways of thinking is needed
API Layer
Do not do transformations
Do not execute logic
It must be nothing more than an aggregated proxy for all of your service offerings
Stick with asynchronous communication
Use message broker (Message queue)
Stream data platforms
Plan of unification processes
Logging
Create unique token (trace) for each call and use it's value for each logging event in each service
ImplementCI/CD on early stages
Build
Deploy
Unit test
System test
E2E test
Do not write any code line unless you have this whole process
Architectures
Hierarchical Service Architecture
Many thought leaders are opposed to this model
It prevents circular dependencies
You define rules about which service type can or can't consume other service type
It models an N-tier architecture via services instead of modules
Data service
Exposes data domain-specific logic completely to outside world
Business Process Service
Business processes that are well-defined
Edge Service
Expose data and business processes to the outside world
Outbound edge service
Expose your client's specific needs to the outside world
Inbound/Translation edge service
Abstract you from third-party dependencies
Gateway Service
Build abstractions over external dependencies
Service-Based Architecture
Single underlying database
Leverages services to handle decomposition
Gains some agility without modifications to data stores
