microservices architecture @ ctrip v1.1

MicroService Architecture @Ctrip

William Yang(杨波 )Dev Manager & Architect

@Ctrip.com

Problem Domain

• System decoupling for deployability and scalability

• Evolutionary architecture and adaptive organization

• Mobile Backend Architecture

Agenda

• The curse of the monolith• Case study – decomposing Ctrip mobile

backend into microservice• Microservice best practice• What we have learned

Initial Ctrip Mobile Backend Architecture

Monolithic Mobile Service

SBU A SBU B SBU C SBU D

SOA/ESB

Pros & Cons

• At the beginning …simple to develop, test, deploy and scale

• Later …huge, complex, monolithic mobile service

The Curse of the Monolith• Bloated codebase• Communication and coordination cost• Obstacle for frequent deployments• Little resilience to failure• Commitment to a single technology stack• Hindering innovation

MicroService Architecture Style

• Decomposing a single app as a suite of services• Communicating with lightweight mechanism• Built around business capabilities• Independently deployable• Minimum of centralized management• May be written in different programming languages

and use different storages

http://martinfowler.com/articles/microservices.html

Who has Migrated to MicroService

http://microservices.io/patterns/microservices.html

New Mobile Backend Arch @Ctrip

Key MicroService Infrastructure

• Service– Service framework, gateway, registry

• Monitoring– Logging, tracing, metrics

• Deployment– TEST/UAT/PROD environments– CI/CD

• Push common concerns to technical infrastructure

MicroService Framework @Ctrip

Service Metrics Monitoring

MicroService Availability

• Assume a monolithic service with 99.99% availability, what if you have ~30 microservices each with 99.99% availability??

• Combined effective availability== 2 HOURS of downtime per month== 99.7% uptime!!

Service Dependency

Single Dependency Delay

Cascading Failure at Peak Hour

Basics of Service Fault Tolerance

• Circuit Breaker(Fuse Blow)• Isolation• Rate Limiting• Fallback

Hystrix Circuit Breaker

http://github.com/netflix/hystrix

Ctrip Gateway Hystrix Dashboard

MicroService Gateway

Gateway Filtering Mechanism

Origin Server

“ pre” filters “ routing” filter(s) “ post” filters

“ error” filters

HTTP Request

Http Request Http Response

https://github.com/Netflix/zuul

Filter Management

Advanced Usage of Gateway

• Surgical debugging• Stress testing• Canary testing• Service migration• Load shedding• Active/Active traffic management

Migration to MicroService Achievement @Ctrip

• System decoupled and domain ownership clarified

• Business innovation speed accelerated• Overall system reliability improved• Decentralized architecture w/o SPOF• Develop, test, deploy and scale independently• Evolutionary architecture

What We Have Learned One

• Smooth Migration– Give buffer to user for migration

What We Have Learned Two

• Follow Architecture & Design Best Practice– Single responsibility & separation of concerns– Dependency inversion– Dependency isolation– Rate limiting & circuit breaker– Dynamic deployable & re-configurable

• Top-Level Design– Fit service into infra, not fit infra into service

What We Have Learned Three

• Conway’s Law– “Any organization that design a system(defined

broadly) will produce a design whose structure is a copy of the organization’s communication structure” – Melvin Conway, 1968

– “Those system then constrain the options for organizational change” – Dan North

Caveat

• MicroService is not a Free Lunch– Significant operations overhead– Substantial DevOps skills required– Implicit interface– Duplication of effort– Distributed system complexity– Testability challenges

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

Future – Soft Load Balancing

Future – Cross Data Centers

Fallback

About Me

• William Yang(杨波 )• Dev Manager & Architect @Ctrip Middleware

Team @Shanghai

We are hiring!

谢谢