PHP Symfony MicroServices Migration @MeeticTech

Symfony
Micro-services
@Meetic

Who am I ?
Joined Meetic in 2014
Interested by their volumes,
functionnal richness and experience
Etienne Broutin
Software Architect

Started in 2001
•
Active in 15 countries
•
Dating leader in Europe
•
Millions of Monthly Active Users
•
150 people in IT teams

2013 Reasons for refactoring plan
Unmaintainable code
Duplicates
Untestable
Need elders validation
Unable to monitor
Continue on failure policy
Based on global log volume

2013 Initial project
Webservices
Backoffices
Mobile Web
WAP
Desktop
Cronjobs
…
Exposition Layer
Private webservices

Started
So cute in the
beginning !

But new issues
Duplicated business logic
Merge conflicts
Longer tests (40min)
Refactorings started to become more and more difficult

We were building a new monolith !
Only 15% of business features
Only 10 developers, target 40

Micro-service pros
• Simpler design phase
• Manage refactoring impacts
• Faster feedbacks by software factory
• Faster deployments
• Real ownership by developers, easier upgrades

Micro-service cons
• Implementation of interfaces
• Response time
• CPU and network usage
• Time to setup a new application
• Can also become hard to understand

New stack
Exposition Layer
Event bus
Consumers
Micro-services
BackOffices
Webservices

2 years later....
Micro-service design
Dependencies
Team
Production

How to split ?
Functionnal splitting
Built around a concept
Pictures Right

What size ?
25 micro-services
9 avg route count
7k avg NLOC
4 avg relationnal tables
to understand
a micro-service
1 to 2
days

Testability
Build in 3minSimpler functionnal
tests

Modelization
POST /photos/{accountId}
GET /photos/{accountId}/{photoId}
PUT /photos/{accountId}/{photoId}
DELETE /photos/{accountId}/{photoId}
POST /boost/{boostId}/increment
REST approach Commands

Data isolation
Strong and difficult choice But
• brings scalability
• brings visibility
• data consistency
• enables caching
• manage data migration

Limits of data isolation
Build a denormalized
database
OLTP
Reactive (event bus)
Batch processing
BI

How to deal with
dependencies ?

Product team has a new idea...

In practice
2/3 of our micro-services
do not depend
on another micro-service
took several
refactorings for that

Defining perimeter is the key
Messages Authentication
nickname
business model
account status
Photo Announce Moderation
Photo +
Moderation
Announce +
Moderation

Event bus to manage dependency
Event bus
Consumer
Consumer
Profile Mailing Optin

get photos
Pattern 1 : Pull data
- performance
- reusability
does have a
photo itself ?can see photos ?
+ hides complexity for clients
+ fast change of business rules
Exposition Layer
Rights Photo

Pattern 2 : Push data from client
+ mutualize data fetching - harder to change if multiple clients
send message
Exposition Layer
Rights
Message
conversation
already started ?
can start
a new conversation ?

Pattern 3 : Store data
Event bus
read message
Exposition Layer
Message
get visible
messages
Blacklist
+ performance
+ reusable
- long to implement
blacklist added
hide messages

Other tips
Batch calls
GET /photos/{accountId}/14,15,21
Parallelize calls
using Guzzle promise

Context
Several independent agile teams
No strong synchronization
Continuous deployment
15 deployments
per day

How do you manage compatibility ?
No versioning
• used internally
• less maintenance
• interface backward compatible

Automated environment
Scripts with docker
compose

Can I use any
framework ?
Any
langage ?
Any database ?

Common interface
• REST + JSON
• Naming conventions
• Security
• Common build
• Common deployment chain

Don’t waste time : need a common basis
Micro-services chassis
• Security
• Logging
• HTTP Interface
• DB & cache components

Share knowledge with non-tech teams
Talkative names
Visibility for project management
profile will be
updated soon
changes on
message are
ready
thanks

Documentation
Inventory
<<<
Call graph generated
from Elastic Search
GET /profile/{accountId}
Profile
Exposition Layer
Right
Backoffice
4%
85%
11%

Ownership
More initiatives
More refactorings
More upgrades
More monitoring

Hosting concerns
It will overload the network !
It will take time to configure !
We will need much more
servers !

Figures
1B calls / day
25ms response time
100 servers
Who calls micro-services ?
Exposition LayerEvent Bus
Micro-services

Networking
• Every Micro-services deployed on
each server
• Affinity for inter micro-service call
Have not experienced need for :
• Service isolation
• Network constraints

8 ms
Symfony boostrap overhead
limited by application size
17 ms
25ms
Cost : 25%

Monitoring Alerting
Elastic Search + Logstash +
Kibana
• Easy to locate errors
• Performance analysis
Monitoring route for every
dependency
GET /profile/{accountId} 11ms 100%
POST /profile/ 42ms 99.992%
...
P
P

Design for failure
Objective 99.999%
Internally : analyse logs
Externally : implement fallback behavior
Exposition Layer
99.9% 98.3% 99.2%
Reliability < 97.4%

Re-usability
Re-used micro-services
from acquisition fusion
Used for several products

Huge opportunity for Data
Best Database for each
Scalability

Feedback on that choice
For Meetic, this architecture was a good choice :
• Symfony helps standardization
• Can scale teams
• Clear implementation of all features
• Answer business needs

PHP Symfony MicroServices Migration @MeeticTech

Recommended

More Related Content

What's hot (20)

Similar to PHP Symfony MicroServices Migration @MeeticTech (20)

Recently uploaded (20)

PHP Symfony MicroServices Migration @MeeticTech