A Look At Micro Service Architecture

78cb08b10705a9d56888236115dfe7e5?s=47 geevcookie
October 03, 2014

A Look At Micro Service Architecture

Micro-Service architecture has been around for a while now, but there is still no clear way to implement it in PHP. During this talk we will be taking a look at a couple of ways to implement it.

78cb08b10705a9d56888236115dfe7e5?s=128

geevcookie

October 03, 2014
Tweet

Transcript

  1. A Look At Micro Service Architecture

  2. Oh Hai There • My name is Zander Janse van

    Rensburg • I'm the lead PHP developer at BlackLight • Organizer of JoburgPHP1 1 JoburgPHP is so awesome that some of the CPT guys have considered flying up to join our meetups.
  3. Places You Can Find Me • Github: geevcookie • Twitter:

    geevcookie or joburgphp • Web: http://geevcookie.com/ • SpeakerDeck: geevcookie
  4. Help Me Help You http://tinyurl.com/micro-services-talk

  5. Them Slides http://tinyurl.com/them-slides

  6. Story Time

  7. Monolithic/Layered

  8. Monolithic/Layered • Built as a single unit (All business logic,

    view, and data persistence in same application) • Default architecture when using popular modern frameworks
  9. Pros • Easy to understand (If properly structured) • Most

    of us are used to this form of architecture • Easy to document
  10. Cons • Entire app needs to be built on deployment

    • Entire app needs to be up and running for development • Can be frustrating and cause technical debt if not managed properly
  11. Micro Services

  12. There is no precise definition for micro services. - Me

  13. Micro Services • Small independent pieces of code • Less

    than 100 lines of code • Smart Endpoints / Dumb Bus
  14. Pros • Can be deployed separately • Can be developed

    separately • Easy for new developers to start development • Code is disposable • Can be coded in any language (Well almost... When done properly)
  15. Cons • Steep learning curve (Without proper guidance) • More

    management required
  16. Evil Cycle Of Technical Debt

  17. Common Cause Of Technical Debt • Laziness • Inexperience •

    Sloppy Code
  18. HTTP As Bus

  19. HTTP As Bus • Responds to JSON RPC • Self

    contained "mini apps" • Needs to live under web server document root
  20. Pros • Easy to understand • Easy to implement

  21. Cons • Not really scalable • Hard to configure

  22. RabbitMQ As Bus

  23. RabbitMQ As Bus • Long running service connected to RabbitMQ

    queue • Uses RabbitMQ's built in RPC functionality
  24. Pros • More scalable • RabbitMQ clusters • Multiple services

    can listen to same queue • Still fairly easy to understand (With some help)
  25. Cons • Requires more management • Harder to get up

    and running on dev's machines
  26. The Hero • Bindings for multiple languages • No extra

    services required • Highly customizable
  27. ZeroMQ

  28. ZeroMQ • Carries messages across inproc, IPC, TCP, TPIC, multicast.

    • Smart patterns like pub-sub, push-pull, and router-dealer. • High-speed asynchronous I/O engines, in a tiny library. • Build any architecture: centralized, distributed, small, or large. • Free software with full commercial support.
  29. Some Supported Languages Ada, Bash, Basic, C, Common Lisp, C#,

    C++, delphi, Erlang, F#, Flex, Go, Haskell, Haxe, Java, Lua, Node, Objective-C, Perl, PHP, Python, Ruby, Scala, Tcl, Smalltalk
  30. It's a library!

  31. Request/Response

  32. Request/Response • Direct connection between app and the end point

    • Uses TCP connections
  33. Pros • Smart end points are easy to create •

    Services can be on different servers
  34. Cons • Only one service per "task" • No reliability

    checks
  35. Request/Response Broker

  36. Request/Response Broker • App connects to a broker • Broker

    manages connections to end points
  37. Pros • Round robin load balancing between end points •

    Services can still be located on different servers • More reliability
  38. Cons • Still not enough reliability. • More end points

    available, but are they really still there • Broker is still a single point of failure
  39. Request/Response Broker (Heartbeat) • Added heartbeat functionality • Broker constantly

    checks if end points are still connected • End points constantly check if broker is still accessible • Client has proper timeouts and retries
  40. Pros • More reliable • Constant logs of communication between

    broker and end points • Better client connection
  41. Cons • Could still improve load balancing

  42. Request/Response Broker (Balanced)

  43. Request/Response Broker (Balanced) • App still connects to broker and

    broker distributes to end points • Brokers communicate to offload extra jobs
  44. Pros • Much more scalable • More more reliable •

    Better load balancing
  45. Cons • Harder to manage

  46. Monitoring (Supervisor) • Checks if services are running and restarts

    if required • Provides stop/start/restart functionality to services via control script • Adds API to check status of services etc.
  47. Config (etcd) • High available key-value store • Inspired by

    Apache Zookeeper • RESTful API
  48. Management (Yogurt) • Talks to Supervisor, etcd, and custom client.

    • Can install client to servers automatically. • Provides easy scaling of services.
  49. Big Dreams • Self healing and scaling solution • Connects

    to provider such as Digital Ocean to scale servers as well • Logstash and Machine Learning provides accurate(ish) scaling based on history
  50. Some Links • http://www.rabbitmq.com/ • http://zeromq.org/ • http://logstash.net/ • http://prediction.io/

    • https://github.com/geevcookie/zeromq-php- helpers
  51. The End