Gilmour: GopherCon London

Transcript

1. GILMOUR DESIGN PATTERNS IN MICRO-SERVICES ARCHITECTURES & * THIS TALK IS BUZZWORD COMPLIANT.
2. MICROSERVICES & GILMOUR?
3. ABOUT WHO AM I? ▸ Twitter: @meson10 ▸ mailto: piyush@piyushverma.net ▸ piyushverma.net
4. SOA (VS SERVERS) WHAT ARE SERVICES? ▸ Logical Entities. ▸ Independent. ▸ Comprised of more services. ▸ Multiple instances. ▸ Scalable. ▸ Flexible.
5. WHODUNNIT WHY ARE SERVICES? ▸ Software Problem ▸ Heterogeneity ▸ Flexibility ▸ Scalability ▸ Management Problem ▸ Authority ▸ Responsibility.
6. DESIGN PATTERNS
7. REQUEST RESPONSE Boomerang
8. REQUEST RESPONSE CALLER SERVICE HELLO? ALOHA! WRONG NUMBER SENDER_ID CODE
9. REQUEST req := g.NewRequest(“message.echo”) data := G.NewMessage().SetData("hello?") resp, err := req.Execute(data) fmt.Println("Echoclient: received", resp) g.ReplyTo(“message.echo", func(req *G.Request, resp *G.Message) { var msg string req.Data(&msg) //Parse data from incoming request. resp.SetData(“Pong") //Send response. }, opts) RECEIVER REQUEST
10. ASYNC / SIGNAL-SLOTS
11. ASYNC: SIGNALS AND SLOTS Slots Signal EVENT.POWER_UP EVENT.* EVENT.* GROUP: REVENUE FP SCALING PUSH MESSAGE SERVER ADS/ MARKETINGSERVER ANALYTICS/ LOGS BADGES/ UNLOCKS EVENT.* ADS/MARKETING GAME GILMOUR EVENT EVENT.BRIDGE_FALL FALL FROM BRIDGE FALL FROM BRIDGE FALL FROM BRIDGE GROUP: BRIDGE_FALL
12. ASYNC: SLOTS g.Slot("example.log", func(req *G.Request) { var msg string req.Data(&msg) log.Println(req.Sender(), "->", msg) }) msg := G.NewMessage().SetData(“log message emitted”) g.Signal("example.log", msg) SIGNAL RECEIVER / SLOT
13. SIGNAL-SLOT VS. REQUEST-RESPONSE
14. ASYNC VS SYNC: WHAT TO USE WHEN? REQUEST-RESPONSE ▸ Confirmed delivery. ▸ Response or Error; Guaranteed. ▸ HTTP-like. ▸ Sender responsible for Errors.
16. ASYNC VS SYNC: WHAT TO USE WHEN? SIGNAL-SLOTS ▸ Broadcasting. ▸ Wildcard topics. ▸ UDP-Like. ▸ Ok with unreliable delivery. ▸ Receiver responsible for Errors.
17. ERRORS: REQUEST - RESPONSE CALLER SERVICE HELLO? WRONG NUMBER SENDER_ID CODE ERROR REPORTER HYSTRIX PAGER DUTY HONEY BADGER EMAIL ALERTS
18. ERRORS: SIGNAL - SLOTS WEB GILMOUR EMAIL NOTIFIER SMS NOTIFIER PUSH MESSAGE Slots Signal PAGER DUTY HONEY BADGER EMAIL ALERTS ERROR REPORTER GILMOUR.ERROR
19. DISCOVERY & LOAD-BALANCING
20. LOAD BALANCING - TYPICAL NOTIFICATION SERVER 1 REPLICATED LOAD BALANCER X.Y.Y.Z? CALLER SERVICE REGISTER I, AM HEALTHY? NOTIFICATION SERVER 2 NOTIFICATION SERVER 3
21. LOAD BALANCING : GILMOUR NOTIFICATION SERVER 2 GILMOUR MANAGER.NOTIFICATION NOTIFICATION SERVER 1 NOTIFICATION SERVER 3 MANAGER.NOTIFICATION MANAGER.NOTIFICATION CALLER SERVICE MANAGER.NOTIFICATION {“NOTIFICATION”: “DATA”}
22. DISCOVERY AND LOAD BALANCING LOOK MA, NO SERVICE DISCOVERY ▸ Gilmour works on Subscriber Publisher. ▸ No querying discovery process. ▸ Call service and not servers.
23. DISCOVERY AND LOAD BALANCING LOOK MA, NO LOAD BALANCING ▸ Has Capacity, Will Serve. ▸ Message delivered to one and all. ▸ Fittest node acquires lock first.
24. ERRORS: DETECTION & HANDLING
25. GILMOUR ERRORS ERROR DETECTION ▸ Timeout: ▸ Server-side - Execution expired. ▸ Client-side - Response too late. ▸ Confirm Subscribers or 404. ▸ Distinguished network failures.
26. GILMOUR ERRORS ERROR HANDLING ▸ Ignore ▸ Publish ▸ Queue func main() { redis := backends.MakeRedis("127.0.0.1:6379", "pass") g := G.Get(redis) //g.SetErrorPolicy(protocol.ErrorPolicyQueue) //g.SetErrorPolicy(protocol.ErrorPolicyIgnore) g.SetErrorPolicy(protocol.ErrorPolicyPublish) }
27. ERRORS: type GilmourError interface { Marshal() ([]byte, error) GetTopic() string GetSender() string GetCode() int GetTimestamp() string GetRequestData() string GetUserData() string GetBacktrace() interface{} } type gError struct { topic string //topic to which the request was sent requestData string //request payload userData string //implementation dependent information sender string //sender from the request timestamp string //timestamp of error backtrace interface{} //backtrace of the error code int //response code (non-200) } ERROR IMPLEMENTATION
28. GILMOUR ERRORS ERROR SAMPLE
29. OPS: MONITORING
30. OPS: MONITORING SERVERS ▸ Logging ▸ Error Reporting ▸ Health
31. OPS: MONITORING SERVICES ▸ Are the services servicing? ▸ Do services have spare capacity? ▸ Do services respond in time? ▸ Health Bulletin: github.com/gilmour-libs/health-bulletin
32. OPS: MONITORING
33. OPS: MONITORING
34. OPS: MONITORING Feb 23 12:25:14 qa-next-backend-manager0.datascale.io gilmour_health: D, [2016-02-23T06:55:12.930435 #22111] DEBUG -- : Ensuring topics have at least one subscriber Feb 23 12:25:14 qa-next-backend-manager0.datascale.io gilmour_health: D, [2016-02-23T06:55:12.931160 #22111] DEBUG -- : Ensuring that gilmour servers respond to health ping Feb 23 12:26:14 qa-next-backend-manager0.datascale.io backend_manager: D, [2016-02-23T06:56:12.932775 #9605] DEBUG -- : Executing handler for gilmour.health.ip-10-0-0-146-pid-9605-uuid-9d0484dd-08e5-4ec3- a3e4-9a109634712b from 2881867d41f24228b462b9eff0b7e88e 2016-04-03 00:06:56 d0e4ea929645600e2fa97657091613a4 -> Cleared VPC jenkins-backend-manager-pipeline-qa-17 2016-04-03 00:06:56 d0e4ea929645600e2fa97657091613a4 -> Clearing databag customer_jenkins-backend-manager- pipeline-qa-17_config::vpc_config 2016-04-03 00:06:57 d0e4ea929645600e2fa97657091613a4 -> Deleted data_bag[customer_jenkins-backend-manager- pipeline-qa-17_config] 2016-04-03 00:06:57 d0e4ea929645600e2fa97657091613a4 -> Clearing DNS entries 2016-04-03 00:07:00 d0e4ea929645600e2fa97657091613a4 -> Cleaning Chef environment 2016-04-03 00:07:01 d0e4ea929645600e2fa97657091613a4 -> Deleted customer_jenkins-backend-manager-pipeline- qa-17 REQUEST LOGGING
35. 
 COMPOSITIONS
36. COMPOSITION ▸ compose - service1 | service2 | composition3 ▸ andand - service1 && service2 && composition3 ▸ oror - service1 || composition2 || service3 ▸ batch ▸ (service1; service2; service3) > out ▸ service1; composition2; service3 > out ▸ parallel ▸ lambda functions
37. COMPOSITION popular := g.NewParallel( g.NewRequestComposition("example.popular3"), g.NewRequestComposition("example.popular4"), ) batch := g.NewPipe( g.NewRequestComposition("example.fetch"), g.NewRequestComposition("example.words"), g.NewRequestComposition("example.count"), popular, ) data := G.NewMessage() data.SetData("https://s3.amazonaws.com/ds-data-sample/test.txt") msg := <-batch.Execute(data)
38. COMPOSITION popular := g.NewParallel( g.NewRequestComposition("example.popular3"), g.NewRequestComposition(“example.popular4"), g.NewRequestComposition("example.popular5"), ) batch := g.NewPipe( g.NewRequestComposition("example.fetch"), g.NewRequestComposition("example.words"), g.NewRequestComposition("example.stopfilter"), g.NewRequestComposition("example.count"), popular, &MyComposer{}, ) 
 data := G.NewMessage() data.SetData("https://s3.amazonaws.com/ds-data-sample/test.txt") msg := <-batch.Execute(data)
39. COMPOSITION batch := e.NewPipe( e.NewRequest("weather.fetch"), e.NewRequest("weather.group"), e.NewParallel( e.NewPipe( e.NewLambda(monthLambda("jan")), e.NewParallel( e.NewRequest("weather.min"), e.NewRequest("weather.max"), ), ), e.NewPipe( e.NewLambda(monthLambda("feb")), e.NewParallel( e.NewRequest("weather.min"), e.NewRequest("weather.max"), ), ), ), )
40. DEMO Please contact to advertise here.
41. SAMPLE TEXT
42. EXAMPLES: POPULAR WORD COUNT ▸ Given ▸ A S3 URL pointing to a file that has (lot of) random text. ▸ Goal ▸ Eliminate stop words from the file. ▸ Find most popular 3, 4, and 5 letter words. ▸ Find these in parallel.
43. EXAMPLES: WEATHER AGGREGATION ▸ Output ▸ Popular 3 letter words: [way, for] ▸ Popular 4 letter words: [Text, copy] ▸ Popular 5 letter words: [Blind, blind]
44. EXAMPLES: COMPOSITION
45. GILMOUR RECAP ▸ No Load Balancer ▸ No Service Discovery ▸ Signal, Slots. ▸ Broadcast using Wildcard Topics. ▸ Exclusion groups. ▸ Sync - Request, Reply ▸ Error and Health Monitoring - HealthBulletin. ▸ Failure Detection ▸ Composition - Real micro-services. ▸ No message persistence.
46. GILMOUR CREDITS & LINKS ▸ Aditya Godbole ▸ Amit Sethi ▸ Mohan Dutt ▸ Poorva Mahajan ▸ Datascale.IO datascale.io ▸ Repository github.com/gilmour-libs