Microservices

Microservices

What are Microservices?

Decomposition patterns

  • Decompose by business capability
  • Decompose by subdomain

Sub Domains

  • Records Management (Document Repository)
  • User Management (Users/Roles/Permissions)
  • Workflow (Customizable Workflow)
  • Master Data Management (Contract/Opportunity etc.)

Steps

  1. Use app credential to get/create/update/remove records instead of user credential in records management
  2. Abstract record entities with relationship with actual records (record unique key and uri)
  3. Abstract master entities relationship with record entities. e.g. Contract, Opportunity.
  4. Create customizable workflow for specific master entity. e.g. specific type of Contract.
  5. Create users with assigned roles (generic for specific type of master entity) and permissions (for specific record)

Architecture Styles

  • Microservices Architecture
  • Event-Driven Architecture

Microservices
Benefits:

  • Agility. Because microservices are deployed independently, it's easier to manage bug fixes and feature releases.
  • Small, focused teams. A microservice should be small enough that a single feature team can build, test, and deploy it. Small team sizes promote greater agility.
  • Small code base. In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.
  • Mix of technologies. Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.
  • Fault isolation. If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).
  • Scalability. Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application.
  • Data isolation. It is much easier to perform schema updates, because only a single microservice is affected.

Microservices on AWS

  • Container - Amazon Elastic Container Service (ECS)
  • Serverless - AWS Lambda
  • Other
    • API Gateway pattern - Amazon API Gateway
    • Caching - Amazon ElastiCache Redis
    • Messaging - Amazon Simple Queue Service (SQS)
    • Pub/Sub - Amazon Simple Notification Service (SNS)
    • NoSQL - Amazon DynamoDB

Input -> Lambda -> DynamoDB -> Batch Job -> Database

AWS Microservices
Microservices on AWS

Monolithic vs. Microservices Architecture
c4c822d8d72486eb3e5d722029677f1a.png

Cloud Services

  • Compute
    • Containers
      • Amazon Elastic Container Service (ECS)
    • Serverless
      • AWS Lambda
  • Storage & Databases
    • Caching
      • Amazon ElastiCache
    • Object Storage
      • Amazon S3
    • NoSQL Databases
      • Amazon DynamoDB
    • Relational Databases
      • Amazon RDS
      • Amazon Aurora
  • Networking
    • Service Discovery
      • AWS Cloud Map
    • Service Mesh
      • AWS App Mesh
    • Elastic Load Balancing
      • Application Load Balancer
      • Network Load Balancer
    • API Proxy
      • Amazon API Gateway
    • DNS
      • Amazon Route 53
  • Messaging
    • Message Publishing & Subscription
      • Amazon Simple Notification Service (Amazon SNS)
    • Message Queuing
      • Amazon Simple Queue Service (Amazon SQS)
  • Logging and Monitoring
    • API Monitoring
      • AWS CloudTail
    • Application and Resource Monitoring
      • Amazon CloudWatch
    • Distributed Tracing
      • AWS X-Ray
  • DevOps
    • Container Image Repository
      • Amazon Elastic Container Registry (Amazon ECR)
    • Continuous Delivery
      • AWS Developer Tools

MMR Microservices Expectations

  • Individual compute
  • Individual deployment
  • Scalable
  • Small team
  • Decoupling
  • Free tech selection
  • No impact to existing apps

AWS Microservcies

  • Container
  • Serverless

MMR Integration Patterns

Source Target Method
Upstream App MMR Read
Upstream App MMR Write
MMR Downstream App Read
MMR Downstream App Write

Implementing Microservices on AWS (Web)
Implementing Microservices on AWS (PDF)
AWS Cloud Map service discovery for serverless applications
Guide to Implementing Microservices On AWS [With Examples]
Service connectivity inside and outside the mesh using AWS App Mesh (EC2/Fargate)

Implementing Microservices on AWS
Contents

  • Abstract
  • Introduction
  • Simple Microservices Architecture on AWS
    • User Interface
    • Microservices
    • Data Store
  • Reducing Operational Complexity
    • API Implementation
    • Serverless Microservices
    • Deploying Lambda-Based Applications
  • Distributed Systems Components
    • Service Discovery
    • Distributed Data Management
    • Asynchronous Communication and Lightweight Messaging
    • Distributed Monitoring
    • Chattiness
    • Auditing
  • Conclusion
  • Contributors
  • Document Revisions

There are three common patterns that we observe when our customers build microservices: API driven, event driven, and data streaming.

Microservices architectures are not a completely new approach to software engineering, but rather a combination of various successful and proven concepts such as:

  • Agile software development
  • Service-oriented architectures
  • API-first design
  • Continuous Integration/Continuous Delivery (CI/CD)

SOA, Service Oriented Architecture
XaaS, Everything as a Service
IaaS, Infrastructure as a Service
PaaS, Platform as a Service
SaaS, Software as a Service

Microservices

  • Decoupling of services
  • Data store autonomy
  • Miniaturized development
  • Testing setup
  • Facilitate faster time-to-market
    c5ec5f6bef1acd41b7b1774df8b5e054.png

How to choose the right data store for your miceroservices?

  • Performance
    1. Read performance
      operations-per-second
      how fast you can run queries
      how fast you can retrieve results
      how well you organize and index data
    2. Write performance
      operations-per-second
    3. Latency
    4. Resource efficiency
    5. Provisioning efficiency
  • Reliability
  • Data modeling

For read/write operations-per-second

  • Very high — Greater than one million
  • High — Between 500,000 and one million
  • Moderate — Between 10,000 and 500,000
  • Low — Less than 10,000

For latency

  • Low — Less than one millisecond
  • Moderate — one to 10 milliseconds
  • High — Greater than 10 milliseconds

Data Modeling Requirements
ae14d9bcebe1a95322ba26f7fdbd53e7.png

Nature of Data
9dec27b7610dda36fd21c458cf48d8a0.png

  1. Transient data

  2. Ephemeral data

  3. Operational data

  4. Transactional data

868b9afe6a80b012237f464fd4299df0.png

Vendor Service Domain Product Certification Status Current Availability
AWS Database Services ElastiCache -- GA 1.0

[Choosing the Right Database for Microservices Solutions](file:///C:/Users/chikun.cui/Downloads/MMateev-SQLSat823Israel-Choosing-the-Right-Database-for-Microservices-Solutions.pdf)

Effective Microservices: 10 Best Practices
10 Microservices Best Practices for the Optimal Architecture Design
Adopting Microservices at Netflix: Lessons for Architectural Design

Creating Cross Tab Queries and Pivot Tables in SQL
SQL Server Cross Join
Crosstab queries using PIVOT in SQL Server
Use SQL Server to Create a Cross Tab Query
SQL Server Hardware Performance Tuning
How Monitoring Query Performance Can Help You Save SQL Memory Usage

Ten Common Database Design Mistakes
SQL Server database design best practices and tips for DBAs

Best Practice - An Introduction To Domain-Driven Design

martinFowler.com tagged by: domain driven design

AWS Microservices

  • Compute
    • Containers - Amazon Elastic Container Service
    • Serverless - AWS Lambda

Cloud Product Catalog

Vendor Service Domain Product Certification Status Current Availability
AWS Compute Services Elastic Container Service (ECS) Blueprint In Progress 1.0 Not Available
AWS Compute Services Lambda -- GA1.0

Azure Microservices

  • Microservices Approches
    • Service Fabric
    • Azure Kubernetes Service (AKS)
    • Azure Functions
    • API Management

Cloud Product Catalog

Vendor Service Domain Product Certification Status Current Availability
Azure Compute Services Service Fabric Clusters -- Beta 1.0
Azure Compute Services Function Apps -- GA 1.0
Azure Enterprise Integration API Management Services -- GA 1.0

GCP Microservices

  • Google App Engine
  • Google Kubernetes Engine (GKE)

Cloud Product Catalog

Vendor Service Domain Product Certification Status Current Availability
GCP Compute Services Google Kubernetes Engine (GKE) -- GA 2.0
GCP App Services App Engine -- Beta 2.0

MMR Technical Pain Points

  • Performance Issues
    High volume of data updates have impact on MMR performance.
  • Data Gap on Opportunity data
    Opportunity Data in MMR are from Sales ODS with 24 to 48 hours of delay from source application (MMS). If the Opportunity is not yet available in MMR, users would not be able to perform Opportunity submissions.
    Moreover, Sales ODS does not deliver updates for Opportunities that are not active in the current fiscal year. This impacts company code mapping for AIL reports.
  • Security Model
    Security Implementation in MMR is very granular.
  • Vendor Limitations and Product Maintenance
    Requires VM with desktop experience (does not support CORE). App teams need to raise exception requests
    since the vendor does not support cloud native offerings yet.Time to upgrade product version would take 3-6 months.
  • Data Replication
    MMR Data (both metadata and actual documents) are now replicated on other apps like SEAL and ALICE (like everything).

What are microservices?
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are:

  • Highly maintainable and testable
  • Loosely coupled
  • Independently deployable
  • Organized around business capabilities
  • Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

The pattern language is your guide
The microservice architecture is not a silver bullet. It has several drawbacks. Moreover, when using this architecture there are numerous issues that you must address.
The microservice architecture pattern language is a collection of patterns for applying the microservice architecture. It has two goals:

  1. The pattern language enables you to decide whether microservices are a good fit for your application.
  2. The pattern language enables you to use the microservice architecture successfully.

A good starting point is the Monolithic Architecture pattern, which is the traditional architectural style that is still a good choice for many applications. It does, however, have numerous limitations and issues and so a better choice for large/complex applications is the Microservice architecture pattern.

Avoid the potholes
Thinking of migrating to the microservice architecture? If so, you should look at this presentation about the potholes in the road from monolithic hell and read this series of blog posts about anti-patterns and how to avoid them.

Assess your architecture
If you have built an application with the microservice architecture then take a look at the Microservices Assessment Platform. The platform assesses what you have built and identifies what needs to be improved. It reduce architectural and organizational risk and maximizes the benefits of the microservice architecture.

  1. Key software delivery outcomes
  2. General architecture
  3. Inter-service communication
  4. Deployment and Reliability
  5. Obervability
  6. Externalized configuration
  7. Supporting infrastructure
  8. Libraries and frameworks
  9. Documentation
  10. Organization and process
  1. Key software delivery outcomes
  2. Service design
    A service is an independently deployable, loosely coupled, component with well-defined and focussed responsibilities.
    1. Is the service an independently deployable/executable component?
    2. Does the service implement a business capability?
    3. Does the service have a single responsibility?
    4. Is a service’s datastore private to that service?
    5. Does the service use reliable mechanism, such as sagas, to maintain data consistency across services?
    6. Is the service built using a supported technology stack?
    7. Is the service built using a supported microservice chassis?
  3. Externalized configuration
  4. Inter-service communication
    Services must communicate securely using IPC mechanisms that allow the API to evolve. In addition, a service that uses RPC must use a service discovery mechanism.
    1. Does the service use language neutral communication mechanisms?
    2. Is the service’s API secured?
    3. Do the communication mechanisms support API evolution?
    4. Does the service use service discovery to locate its (REST/RPC) dependencies?
    5. If the application uses client-side registration, Does the service register itself?
  5. Service reliability
  6. Deployment/Release
  7. Observability
  8. Documentation
  9. Automated testing
  10. Organization and process

Microsoft Microservices Architecture

API Gateway
演化路线
1 - 所有容器都在一台机器上使用不同端口利用Nginx映射
2 - 部分容器在单独的机器上，UI使用静态对象

https://github.com/Microsoft/Yams

posted @ 2022-03-31 09:12  桁椽  阅读(122)  评论(0)  编辑  收藏  举报