The document discusses dynamic routing in microservices using Linkerd, a scalable service mesh designed for cloud-native applications. It covers Linkerd's architecture, features such as latency-aware load balancing and connection pooling, and outlines the steps in configuring routing via delegation tables. Key takeaways emphasize Linkerd's ease of configuration, maintenance, and integration, allowing developers to concentrate on coding rather than on service management.

2. Dynamic routing in micro-
service oriented
architecture
Daniel Leon
Optymyze
[13th
of May 2017]

3. Content table
•Dynamic routing role
•Linkerd concepts
•Some exercises for computing a route with
Linkerd
•Demo
•Q&A

4. Why routing ?
•Why now?
•What is the real purpose ?

5. What is Linkerd
•Scalable service mesh for cloud-native
applications
•Built on top of Finagle

6. What Linkerd does ?
• Manages the difficult, error-prone parts of
cross-service communication:
− Latency-aware load balancing
− Connection pooling
− TLS
− Instrumentation etc

7. Linkerd simplified
•Transparent + Reverse proxy
•Being deployed per-host or per-pod every
call is made to the local Linkerd instance

8. Linkerd architecture

9. Step 2 & 3
•Pluggable by configuring the interpreter
attribute in the router configuration
•Can be handled by a separate service called
namerd:
– Dynamic update of routing tables
– Minimal interaction with service discovery
endpoints

10. Step 1 - Identification
•Protocol specific (http 1.1, http 2, thrift,
thriftMux, Mux)
•Request → Service name/logical name
•The logical name maps with the Name
concept in Finagle
•Example for http 1.1 : GET
http://example/hello → /svc/example
•Is handled by a router configuration with the
identifier attribute

11. Step 2 - Binding
•Configured by the client and dtab attributed
in the router section
•Delegation table(Dtab) – ordered list of
delegation which define how a path should be
interpreted
•Delegation – rewrite rule
•Load-balancing options can be specified to
the client section

12. Step 2 - Binding
•Dtab:
– /svc => /datacenter1/cluster1
– /datacenter1/ => /#/io.l5d.fs
•Request → /svc/production
•What is the resolved path ?

13. Step 2 - Binding
•Dtab:
– /svc => /datacenter1/cluster1
– /datacenter1/ => /#/linkerd_resolver
•Request = svc/production
•svc/production →
/datacenter1/cluster1/production
→/#/linkerd_resolver/cluster1/production

14. Step 2 - Binding
•Dtab:
– /svc => /datacenter1/cluster1
– /svc => /datacenter1/cluster2
– /datacenter1/ => /#/linkerd_resolver
•Request = svc/production
•svc/production →
/datacenter1/cluster2/production
→/#/linkerd_resolver/cluster1/production

15. Step 3 - Resolving
•Performed by the namer
•Called by the client of linkerd
•Further specifications in the ‘service’ attribute:
– responseClassifiers
– retries

17. Conclusions for Linkerd
•Easy to configure and maintain
•No code writing is needed
•Scalable and easy to integrate
•Helps developers focus on the actual code
instead on service availability, graceful
degradation or load-balancing

18. Q & A