Microservices Patterns

? Microservices PatternsChapter 1 - Escaping monolithic hellMonolithic hellComplexity is overwhelmingShear size slows Development speedbuilt timeCode merging takes lot of effortEffort to build a stable release means releases slower, which means releases done less frequentlyWorking how to scale solution is a lot more complexReliability - a bug anywhere in the solution has potential to bring everything to its kneesCommitment to a tech stack for the long term - difficult to try different techHow microservices can helpScaling cubeY axis = functional decompositionFunctional decompositionX axis = horizontal duplication aka scaleoutMultiple instances + load balancerZ axis = scaling by data partitioningMultiple instances againEach instance takes on specific data setFronted by smart routing New approach to ensuring modularityData store separationDoesn’t mean separate dB serversProsEnablement of CI-CDEach service small and maintainableIndependent deploymentIndependent scalingAutonomous teamsTrial new tech more easilyBetter fault isolationConsFinding right set of services is challengingGet it wrong you get a distributed monolithDistributed systems are more complex need for IPC etcMultiple versions of the same serviceAutomation for CI/CDAdditional tech such as Docker, kubernetes, opensihift etcDistributed systems are complexDeployment of features that span multiple services need careful considerationUnderstanding dependency chains more complexDeciding when to adopt microservices can be difficultDeciding when to use microservicesEarly solution may not encounter problems that Desmond’s microservicesStarting immediately using microservices will mean paying a premiumAlthough refactoring into microservices can be hard because of tangled dependencies“ startup should almost certainly begin with a monolithic application”Microservice pattern languageNo silver bulletJonathon Haida -The Righteous Mind - Why Good People Are Divided by Politics and ReligionSuck/Rock dichotomy Neal FordFred Brooks - Mythical MonthPattern characteristicsForceProblem in a contextResulting contextBenefitsDrawbacksIssuesRelated patterns - have relationships characterised by..PredecessorSuccessorAlternativeGeneralizationSpecializationExample: Patterns form a pattern languageA set of related patterns that solve problems within a domain often forms what is termed a pattern languagePattern language came from Christopher Alexander - reslworld architectMade up from ...ForcesResulting contextBenefitsDrawbacksIssuesRelated patternsPredecessorSuccessorAlternativeGeneralizationSpecialization Communication patternsNeed to decide the kind of IPC used. Options...Async messagingSync HTTP / RESTSync RPCNeed to decide hoe to do registry and discoveryInter communication via a gateway or directlyHow to handle data consistency2PC not really practicLHow to join data across microservices now they have their own data storesNeed patterns for deployment as there will many pieces to deploy and possible dependency issuesObservability becomes more important now executions can span more environmentsProcesses and organization Mythical Man Month highlights communication overhead of a size n team is O(N^2)Team no more than 8-12 people and focussed on business oriented goalsCross functional teams so can develop, test & deploy services with minimal cross team commsJez Humble3 defines continuous delivery as follows:Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable wayNeed to move fast without breaking thingsHuman dimension...People are emotional thingsIgnore emotions and things get bumpyConcept of transition by William & Susan Bridges describe how people emotionally react to change. The model has the following stages...Ending, losing, letting goEmotional upheaval & resistanceOut of comfort zoneFeel threatened e.g central team work gets distributedDisruption to established teamsNeutral zoneMoving from one way of things to anotherStruggle to change to new waysNew beginningChange is embracedChapter 2 -Decomposition StrategiesAvoid god classes, they can lead to...Tangled dependenciesPrevent decompositionArchitecture importance because it draws out the NFRsCommunication by...APIsRPCMessagingVia DB. Is discouragedIdentifying the system opsprocess is inspired by object-oriented design process described in Craig Larman’s book Applying UML and Patternscreates the high-level domain model consisting of the key classesEstablishes vocabularyDomain model is a simplification of what needs to be implemented - divergent from Eric Evansdomain model is derived primarily from the nouns of the user stories and the system operations are derived mostly from the verbsthe system operations and describe each one’s behavior in terms of the domain model.Can be charactized as eitherCommands - operations typically CUDQueries that read dataUse the verbs in the scenarios / use cases to help identifyCommands haveParametersReturn valuesBehaviours in terms of the classes in the modelPreconditions - conditions that must be valid before the operation is invokedPost conditions - statements of truth after the operation has been invokedAn example Decomposing into servicesDecompose by business capabilityIdentify business capabilities, consider...PurposeStructureProcessesOnce capabilities defined it is possible to define the service(s) that go with itBenefit is if organisation is stable then the architecture will also have stability - Conway’s LawArchitecture may evolve reflecting ‘how’ processes workScenarios to understand service collaborationAssign operations to servicesSometimes assignments are not obvious so look at the relationshipsThere are some problems that will need to be addressedSynchronous IPC reduces availabilityOperations spanning multiple services create need for distributed transactionsDomain Driven Design can help break the occurrence of god classes. God classes limit decompositionSubdomainsBounded contextEach subdomain has its own version of a god class which will be a smaller set than if the object is used across the entire solutionOOW approach defined in Designing Object Oriented C++ Applications Using The Booch Method can be appliedSingle responsibility principleA class should have only one reason to change.–Robert C. MartinIf a class has multiple responsibilities that change independently it will be unstableCommon closure principleThe classes in a package should be closed together against the same kinds of changes. a change that affects a package affects all the classes in that package.– Robert C. MartinIf classes change in lock step they can be in the same packageClasses likely to implement different aspects of a business ruleArticle Principles of Object Oriented ArticleS.UncleBob.PrinciplesOfOodChapter 3 - Interprocess communicationIPC selection can be very influential to solutionFavour async comms internallySync comms with outside worldAPIs evolveBackward compatibilityCompatibility breaking changesSemantic versioninggRPC cross language RPC frameworkNeed to handle partial failureNetflix approach timeouts - never block indefinitely and always use timeouts when waiting for a response. Using timeouts ensures that resources are never tied up indefinitely.Limiting the number of outstanding requests from a client to a service - impose an upper bound on the number of outstanding requests that a client can make to a particular service. If the limit has been reached, then it is probably pointless to make additional requests, and those attempts should fail immediately.Circuit breaker pattern - track the number of successful and failed requests and if the error rate exceeds some threshold then trip the circuit breaker so that further attempts fail immediately. If a large number of requests are failing then it suggests that the service is unavailable and that sending more requests is pointless. After a timeout period, the client should try again and, if successful, close the circuit flix Hystrix Implements these patterns implementation can be seen in Polly discoveryPlatform provided such as Docker and Kubernetes based envsDNS/VIPAsync message basedImplementing request/replyScaling through competing consumersDetect and discarding dupesSending and receiving message as part of dB transactionSee Hhope & WoolfeMessage brokers such asActivemqRabbitmqKafkaKenesisAWS SQSWhen choosing a broker, considerMessage orderingDelivery guaranteesPersistenceDurabilityScalabilityLatencyCompeting consumersChapter 4 - Managing Transactions with SagasThe challenge in a microservice environment is that data may now be owned by different servicesthe de facto standard for distributed transaction management is X/Open Distributed Transaction Processing (DTP) Model (X/Open XA). XA uses 2 Phase Commit (2PC) all dbs Support XA such as MongoDB and CassandraMessage brokers such as RabbitMQ and Kafka don’t support XADistributed transactions utilise synchronous IPC, which raises issues of availabilityCAP theorem, which states that a system can only have two of the following three properties: consistency, availability and partition tolerance - message driven sequence of transactionsSpring provides declarative framework for managing a transaction using @TransactionalSagaSequence of individual transactions scoped to the serviceNext step runs on the completion of the previous 1 Not acid and transaction failures will be more complex to handleMust be able to rollback through the use of compensating transactionsCompensating transactions need to run in the reverse orderSaga can be driven by ...ChoreographyMust have reliable transportParticipant needs to be able to map saga event to its own dataParticipants publish additional information in the saga events to enable other participantsBenefit of this approachNo additional frameworks are needed (assuming choreography is already possible)Coupling remains loseConsCyclic dependencies introduced as 1 service needs to subscribe to another’s event for do and undoData structures could become more complex as state information needs to be handed aroundOne one place that can determine validity of the transaction requested as the knowledge is distributedClarity on how the saga works is a lot harder to followOr orchestrationDefine an orchestrator entity whose sole job is to tell the participants what to doUses a command/reply model of interactionModel the saga orchestrator as a state machineProsTesting a saga is easier as you just exercise the state engineIt is possible to stop a saga prematurely e.g. if a customer cancels an orderAs the saga is a series of mini transactions this has some wider impactssThe changes resulting from each microservice are visible before the saga is complete having potential business logic impactsMultiple concurrent sagas means the transactions will be interwovenWill need to handle the possibility that states are indeterminate whilst a saga has not completedBefore a saga can implement change it could try obtain locks on all entities it needs - this eases the issue of failing because of changing stateLock model does have the change of risking deadlocksChapter 5 - Business Logic in microservices Inbound and outbound layers extrapolate away the implementation/adaptor workNeed to decide if the business service will follow either ...OO approachProcedural approachTransaction script patternIdeal for simple business needsDefined by Martin Fowler 20021 method that handles each event typeKeep these classes separated from classes handling stored stateBe aware of the pitfall of letting the logic grow and become unwieldyDomain model patternAligns more to OOClasses smaller simpler, do one thingPotential for classes to reflect real world making design more understandableRisk of domain boundaries not being clear e.g. deleting an entity which has dependent entities e.g. a order, has line items, fiscal info etcCan overcome problem by aggregating entities to definitive boundaries aggregateAggregate rules#1 Reference only the aggregate root - only the roo part of the aggregate can be referenced externally e. Order not order line#2 inter-aggregate references must use primary keys - each part identifies related elements by an unique Id eg in a ship aggregate the hull is referenced by hullId#3 one transaction creates or updates one aggregateAdaptor invokes Service object which then drives relevant sagas which then interact with individual entities within the aggregatePublish domain eventsReasons for events ...Where replicas need to be maintained those services know that data has changedVia a webhook or message broker next step in a process can be triggeredTrigger async user processes such as emails that order has completedMonitoring of prcoessesEnable the analysis of eventsEvents made up typically of object ids an? meta dataDetails of the event may be in the header/envelope and the event doesn’t carry a payloadConsider enriching the event with the object data to alleviate the need for interested parties to query the entityEvent storming as a technique to tease out the events that maybe or are needed.Identify event triggersSystems that maybe interestedHow time effects the solutionEvents need to be treated as transactional as data - could be achieved by writing to an outbox table which is then used by a message brokerChapter 6 - Developing business logic with event sourcingPersist an aggregate as a sequence of eventsEach event is a state change of the aggregateBenefits ...There is a history of transactionsCurrent state can be achieved by replaying the history of eventsDownsides ...Learning curveQuerying the event store can be difficultUse of Command Query Responsibility (CQRS) patternWeaknesses of relational modelWhen using an ORM there is the object-relational impedance mismatchApplicability of ORM is a polarised debateblogs.post/the-vietnam-of-computer-science/Lack of aggregate historyImplementing audit logging is tedious and error proneEvent publishing is bolted onto business logicTo create an aggregate using event sourcing ...Load the events of the aggregateCreate the aggregate object using default constructorsIterate through the events applying them to the aggregateCreating events is the key, so command such as order x translates to ...Validate the command objectTranslate the command object to a series of state changesApply the state changes with the corresponding events being generatedConcurrency handled by optimistic lockingVersioning numbering on traditional storageCan apply the same to eventing OR use number of events as a proxyWhen an aggregate has lots of events then it can become unperformant, so store snapshots and work foreword ffqComplex structures will benefit from the momento pattern consumers should be idempotent so if a message broker ends up delivering the same message more than once this can be handledUsing a relational dB this can be done by inserting events into a table with part of the message providing a key. If the key exists then doneNoSQL stores need a different approach, here an Id is generated algorithmically and added when writing the object. It can therefore look to see if such an I’d already existsWhat happens when it comes to evolving schemas/data models - as replaying from the 1st event to the latest could mean structural changes in the data representationsConceptually an event sourcing schema is made up of 3 levelsTop level contains one or more aggregatesThe 2nd level represents the events an aggregate emitsLowest level contains the structure of the events Achieve change by upcasting the entities institute much like a traditional relational schema change. Don’t recreate the events.Approach benefits..Reliably publication of domain eventsPreserves the historyAvoids O/R impedance issuesChapter 11 - Deploying Microservices Language specific package patternLanguage based deployment mechanisms such as war filesProsFast deploymentEfficient resource utilisationConsLack of encapsulation of the tech stackLimitations of resource constraining deploymentsLack of service isolation on the same instanceAutomation of resource placement can get complexUsing VMsProsTech stack encapsulationService instance isolatedLeverage mature cloud infraConsLess efficient in resource utilizationDeployment relatively slowSays admin overheadUsing containersBase docker imageDockerfilesDocker registryDocker in Action by Jeff NickoloffKubernetes - as an orchestration framework should coverResource managementSchedulingService managementMake up of kubernetesEach node hasKube -proxy - load balancing across kubletsKublet(s) - manages a pod on a nodeMaster server hasAPI server for rest interfaceEtcd - stores configSchedulerController managerConceptsPod - basic deployment unit made up of one or more containers that share an IP and storage volumeMay include one or more sidecar containers to provide supporting functions e.g. Ng ins to do a git pullPods are ephemeralDeployment - declarative spec of a podService - static end point with own IP and DNSChapter 10 production readyKey capabilitiesConfigurabilityConnections to other services and utilities such as dB as they will change based on deploymentGet config at runtimePush approachRuntime passes in the configurations e.g en vars, providing config files Comes with the challenge of how to get a running system reconfiguredRisk that configuration info gets scattered across multiple config files and related sourcesPull model - get info from a config server Options includeGitDB such as a noSQL DBSpecial servers inc. Spring Config Server, Hashicorp Vault, AWS Parameter vaultBenefits are ...Centralised Configuration dataTransparent encrypt/decryptDynamic configuration changeDownside is another piece of infrastructure needed if not available as part of the platformObservabilityHeath check APIs - endpoint that can provide app health infoThere are circumstances when a service maybe running, but should not receive calls e.g. exhausted dB connections, running but still initialising spring boot actuatorImplements an endpoint called /healthImplements a set of Services based upon the infrastructure services usedHealth check request handler api may perform things like checking the database connectivityUtilise HTTP codes to get status indicatorsNeed to take into account...How is the endpoint implementedEnd point may verify it can access its external servicesImplement a synthetic transactionConfiguration management of the healthcheckDeployment of the health check serviceNo point in having health check end points if they’re not used this can be achieved through the use of Eureka’s configuration. Docker and Kubernetes can be configured to exploit these ends points as wellLog aggregation - logs compiled to a central locationStandardise on a logging library if possibleSend log output to standard out - it’s easier to tap into and consistentLogging infra is needed e.g. ELK Elasticsearch Logstash KibanaDistributed tracking by tagging API calls with an I’d and carrying the tag through all the services Might consider Aspect Orientated Programming (AOP) to inject logging pointsSpring Sleuth can realise AOPStitch the trace I’d events together using tools like Open Zipkin (Zipkin was originally from Twitter)Exception tracking - a central service to report exceptions toShould be a rare eventImportant to provide root causeBetter to have a service rather than just use logs and analytics and alertingA dedicated service means it is possible just to flag the root cause and not all the cascade issues - does require intelligence in the handling ApplIcation metrics - expose endpoints that provide metrics about the application ands its behaviour and performanceMeasure things like...Service latencyNumber of requests executedBusiness related values such as service requests rejected, processed etcMetrics need to be gathered and made available for visualizationSpringboot can make JVM metrics availabileAudit logging - track specific auditable events such as things the user is doingAudit logging in the business codeAudit via AOPEvent sourcingRealise Services using a microservices chassisExamples...Springboot and spring cloudGo Kit and Micro for GoLang downside is each language needs its own chassisService mesh is a low level infra that mediates comms Services and external apps Implements capabilities such as distributed tracing, service discovery, load balancing etcExamples...LinkerdIstioConduitSecurityMany aspects are no different to a monolithSome differences to monoliths when handling securityCan’t share credentials by handing around an in memory object - not practicalUsing a DB to handle security and other session data breaks the dB decouplingDo however need to be able to safely pass identity from service to serviceAspects needing to be addressedAuthenticationAuthorisationAuditAuthentication strategies...Each service authenticates a user...means they have to enter the microservice network 1st1 mistake in the microservices implementation and environment is compromisedHow to deal with different clients authenticate in different ways - not desirable for every service to handle different mechanismsGateway authenticates before forwarding1 place to solve the problem correctlyConsolidation of different auth processes in 1 placeProvides a token to show authentication has occurredRisk of gateway getting too tightly integrated to authentication processesEach service implements access control listsNeed to decide on the token framework to useOpaque tokens often represented as UUIDsDo reduce performance and increase latency as each service needs to talk to a security service to use UUID to retrieve user infoOR use a transparent token form such as JSON Web Tokens (JWT)JWT sets out a stand way of representing claims such as identity and rolesJWT tokens are signed to prevent attempts to forge tokensBecause once a token is produced, no way of revoking it - have to allow it to expireRecommended OAuth reading ActorsAuthorizationServer- provides an API for authenticating users and obtaining an access token and a refresh token. Spring OAuth is a great example of framework for building an OAuth 2.0 authorization serverAccessToken-a token that grants access to a ResourceServer.The format of the access token is implementation dependent. However, some implementations,such as Spring OAuth, use JWTsRefreshToken-along-lived, yet revocable token that a Client uses to obtain a new AccessTokenResourceServer-a service that uses an access token to authorize access.In a microservice architecture, the services are resource serversClient- a client that wants to access a ResourceServer. In a microservice architecture, the API Gateway is the OAuth 2.0 clientProgress: 100%Chapter 9- Testing Mcroservices Chapter 8 - external API patternsExternal API Design considerationsPoor user experience due to the client making multiple requestsLack of encapsulation requires front end devs to change their code in lock step with the backendServices might use client unfriendly IPC mechanisms Open source gateway optionsNetflix ZuulRate limitingAuthenticationFilters Cloud Zulu - use spring mic for the composition, Zulu for routing etcSpring cloud gatewayBuilds on top of several componentsSpring bootSpringSpring webfluxProject reactorEdge functions such as authenticationRouting to backendsRequest handlers 7 - implementing queries in a microservice architectureAs the data you may need could distributed across multiple services a simple query as you would in a monolith isn’t an optionOptions...API composition pattern Composer calls all the components and stitches the results togetherDesign considerations to take into account which component performs the composer, optionsClient is composerIf the client is inside the LAN and firewalls etc then an option - otherwise not recommended API composer performs query Enables API to service external clients effectivelyComposer as a stand-alone service Ideal for supporting multiple internal servicesManage impact of latency etc by calling Services in parrallel if possibleAPI composers if possible use a reactive programming model e.g using tech such as ...Java ComposableFuturesRxJava ObseravblesProsSimpleIntuitiveConsOverheads e.g multiple service callsRisk of reduced availability - mathematical availabilityMitigate availability by accessing cache when service not availableTransactional consistency at riskCQRSBetter for larger data sets Bypass structure to database when performance is a real issueCQRS - separate model to handle non trivial queriesCQRS query model maintained by having event handlerProsefficient implementation of queries in a microservice architectureefficient implementation of a diverse queriesMakes querying possible in an event sourcing-based applicationImproves separation of concernsConsMore complex than api composition but also more powerfulReplication lagViewsAPI consisting of 1 or more query operations ConsiderationsDatabase selection Schema designManaging concurrent updatesIdempotent handling of updatesWhen modifying or adding views need a means by which data models built/rebuiltReplication lag ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download