Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Node.js Web Apps @ ebay scale

1 452 vues

Publié le

eBay journey to Node.js including specific areas that the platform team had to go through to succeed in this process.

Publié dans : Internet
  • Celebrated pianist Scott Henderson says: "I am thoroughly impressed by the system's ability to multiply your investment!  http://t.cn/A6zP2wH9
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • The Surprising Reason 11:11 Keeps Popping-Up: Free report reveals the Universe's secret "Sign Posts" that point the way to success, wealth and happiness. Claim your copy right now!  http://t.cn/AiuvUMl2
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Manifest Absolutely Anything. Discover the Universe's "7 Sacred Signs" that guide the way to unlocking your heart�s greatest desires. Access your free report now! ♣♣♣ https://bit.ly/30Ju5r6
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Attract Abundance Into Your Life - New musical "Angel tone" calls in your angels to help you manifest abundance and miracles into your life... starting in just minutes per day. Go here to listen now. ♣♣♣ https://tinyurl.com/y6pnne55
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Node.js Web Apps @ ebay scale

  1. 1. Node.js Web Apps @ ebay scale
  2. 2. By Dmytro Semenov Member of Technical Staff @ NodeJS, Cloud and Platform Services, eBay Inc. dsemenov@ebay.com
  3. 3. Our Journey
  4. 4. 1995 2004 2013 present2006 Perl C++ XSL/XML Java Node Scala Java UI, JSP Extended Python Go ??? future Marko/Lasso(Tessa) Polyglot initiative OSGi Programming Language History
  5. 5. ● Perl/Apache (no layers) ○ Scalability limit of 50K active listings ● C/C++/IIS/XML/XSL (monolithic client/server architecture) ○ Compiler limit of methods per class, very long build times (2+ hours) ● Java/J2EE (3 tier architecture, split build into domain specific) ○ XML/XSL (MSXSL) as presentation layer hit native memory limit ○ Java UI components, proprietary technology, steep learning curve ○ Startup time up to 40 minutes ● Java Stack (embrace open-source, JSP, modular approach) ○ OSGi conflicts at startup, very hard to get everything working at the start ○ Slow startup time (2+ minutes) ● Polyglot initiative to support popular languages/technologies
  6. 6. Node.JS Introduction
  7. 7. ● Started in 2013 ○ CubeJS, first attempt was not so good, ○ Unified NodeJS, eBay and PayPal platform merge ○ Big projects decided to move to NodeJS ● Embedding into application teams ○ Accumulation of issue knowledge base ○ Build confidence and form local knowledge centers ○ Fast feedback ○ Fast project startup ○ Pick new ideas from application teams
  8. 8. Current State
  9. 9. ● Node 4.x ● 200 applications and growing ● 80 million requests / day now 1 billion ● Platform team of 6 developers ● Very vibrant internal community ○ Local pool of knowledge among teams ○ Self sustaining support by internal community ○ PRs are welcome ○ 45 contributors to eBay NodeJS platform ● 80 platform modules ● 330 total modules
  10. 10. ● More agile ○ Startup time <2s ○ Test coverage close to 90%-100% ○ Faster releases (every day) vs 2 weeks cycle ○ Automatic upgrades with semver ○ Modular UI architecture based on UI components ● Better tools ○ flame graphs, waterfall charts, pre-production testing ● Learnings Applied to Java Platform ○ Incorporate best practices from NodeJS ○ Startup time < 1 minute ○ Embrace modular approach and semver ○ Lighter Java stacks
  11. 11. Architecture
  12. 12. NPM: Private Kappa CouchDB Primary CouchDB Backup replicate registry.npmjs.org npmjs.ebay.com fallback LB Kappa Kappa
  13. 13. Multi-Screen World
  14. 14. mobile web browser native App Server Domain Experience Service services API Gateway ajax
  15. 15. ● Experience Service ○ Provides view models for UI modules ○ View model is specific to the device type (native, size, desktop, tablet) ● NodeJS Web App ○ Talk to experience service ○ Handles UI functionality ○ Renders desktop and mobile web pages ● Native Apps ○ Talk to experience service via API gateway
  16. 16. Module View pm2 node.js express (3 workers) platform-ebay analytics logging config service client lasso plugin app servicespages components kraken-js lasso/tessamarko
  17. 17. Don’t Build Pages, Build Modules
  18. 18. The old directory structure (bad)...
  19. 19. src/ pages/ component s/ src/components/login-form/ index.js style.css template.marko src/pages/login/ index.js style.css browser.json
  20. 20. UI Technologies
  21. 21. ● Async + streaming ● Custom tags ● Browser + Node.js runtime ● Lightweight ● Extremely fast ● Compiles to CommonJS markojs.com github.com/marko-js/marko github.com/marko-js/marko-widgets Templating UI components ● DOM diffing/patching ● Batched updates ● Stateful widgets ● Declarative event binding ● Efficient event delegation ● Lightweight runtime
  22. 22. UI components built using Marko Widgets Uses Marko templates as the view. Plus: github.com/marko-js/marko-widgets ● DOM diffing/patching ● Batched updates ● Stateful widgets ● Declarative event binding ● Efficient event delegation ● Lightweight runtime
  23. 23. Speed is king
  24. 24. Node is built on a streaming interface HTTP is a streaming protocol So why then do most templating and UI libraries render as a single chunk?
  25. 25. ● Faster perceived page load ● Better time, resource and traffic utilization ● Progressive rendering between browser, frontend and backend ○ Frontend<->Backend: Stream of server side events (SSE) ○ Browser<->Frontend: Module render and flush on arrival ● Marko helps: ○ Async fragments support by marko-async ○ Re-order on client side
  26. 26. Marko vs React: Server-side rendering github.com/patrick-steele-idem/marko-vs-react
  27. 27. browser Domain Experience Service http/https http/https chunked stream sse stream App Server
  28. 28. Service Invocation
  29. 29. Why not use middleware pattern on the client?
  30. 30. logging error handling analytics circuit breaker retry security/oauth http/https/sse serviceinvocationhandlers service client middlewares service web app request response cookies body-parser analytics
  31. 31. ● Generic Service Client with pluggable handlers ● Handler performs a single function ● The handler pipeline is configurable per client
  32. 32. Configuration based Code based "my-service-client": { "protocol": "http:", "hostname": "myservice.com", “path”: “/path/to/resource”, "port": 8080, "socketTimeout": 1000, "pipeline": [ "logging/handler", "circuit-breaker/handler", "error/handler" ] } var serviceClient = require(‘service-client’); serviceClient.use(require(‘logging/handler’)); serviceClient.use(require(‘circuit-breaker/handler’)); serviceClient.use(require(‘error/handler’)); serviceClient .get(‘http://myservice.com/path/to/resource’) .end((err, response) => { console.log(response.body); })
  33. 33. Resource Bundling and Externalization
  34. 34. Why not deploy everything at once?
  35. 35. Resource Server App Server 1. GET http://www.ebay.com 2. GET http://rs/check/hp-24512.js 3. PUT http://rs/upload/hp-24512.js 4. <script src=”hp- 24512.js”> 5. GET http://hp- 24512.js 6. GET http://hp- 24512.js Akamai browser
  36. 36. lasso.js/tessa JavaScript module bundler + asset pipeline github.com/lasso-js/lasso
  37. 37. ● Supported resources ○ Defined by lasso plugins ○ CSS/JS/Images ○ Templates ○ I18n content ○ Bundle definition ● Lasso plugin ○ Adaptor between lasso and resource server ● Benefits ○ Single build and deployment ○ No synchronization problems between app and resource server deployments ○ Externalization at startup and during runtime on-the-fly
  38. 38. Configuration Management
  39. 39. app/config.json /node_modules /moduleA/config.json /moduleB/config.json CMS app/1.0.1/config: {} moduleA/1.1.1/config: {} moduleB/1.0.0/config: {} pull every minute Config Deployment App Deployment App Server App Server App Server
  40. 40. ● Module configuration ○ Local, packaged with module ○ Remote, hot deployed ● Application configuration ○ Local ○ Remote, hot deployed ● Application can override any module configuration ● Configuration can be injected via Admin Console ● Future - Code and Config “separation”, but ○ Keep app and config together in git repo and separate at deployment. ○ Easier to manage
  41. 41. i18n
  42. 42. ● Use krakenjs/spud module ○ Property file format ○ Marko tags/helpers ● Externalizable as resources ● 17 main languages ● Support multiple languages per country ● Application and modules can have localizable content
  43. 43. app/locales/ US/ en/ ProjectName/ xxx.properties yyy.properties ru/ ProjectName/ xxx.properties yyy.properties DE/ de/ ProjectName/ xxx.properties yyy.properties Folder Structure Example
  44. 44. Security
  45. 45. ● Nsp tool ○ On-demand scan for every application project ○ Security badge for every platform module ● ScanJS ○ Source code scan ● CSRF tokens ● Redirect validation ● XSS ● Rate limiter
  46. 46. Logging & Monitoring
  47. 47. ● Logging every transaction/subtransaction ○ Central Logging Repository (CAL) provides log aggregation per pool/box/datacenter ○ Use Domains to maintain context per request and avoid passing it around ● Explicit code instrumentation ○ Support DEBUG, INFO, WARN, ERROR, FATAL ○ Time span to record transaction (start and end) ○ Nested spans ● Health checks/stats monitoring and alerts ● Crash/OOM emails to the owner of the pool ● Early problem detection using traffic mirror
  48. 48. App Resiliency
  49. 49. ● Proactive testing in pre-production ○ Traffic mirroring of read-only traffic to the box with new build ○ Easy upgrades ● Handling uncaught errors ○ Domains used to capture context ○ Send email to the owner with stack trace, group and box name, request info ○ Graceful restart ● Handling memory leaks ○ Email sent to the owner with group and box name, request info ○ Graceful restart when memory threshold is reached ● Too busy load shedding ○ 503 or connection reset to trigger browser DNS fallback ○ Filter bots traffic under heavy load ● Planning for failure ● Hystrix like service calls ○ Fail fast ○ Circuit breaker
  50. 50. Performance Optimization
  51. 51. ● Fast startup/re-start ○ Cold cache to avoid service invocation ○ Pre-compiling template @ deployment ○ Pre-externalizing resources @ deployment ● Progressive rendering/streaming @ browser side ● Progressive chunking/streaming @ service side ● Performance tuning ○ Flame Graphs ○ Waterfall charts @ server side
  52. 52. Marko vs React: Server-side rendering github.com/patrick-steele-idem/marko-vs-react
  53. 53. Tools > Flame Graphs
  54. 54. Flame Graphs
  55. 55. Why not use v8-profiler data?
  56. 56. ● How to ○ Use v8-profiler to generate json data file ○ Aggregate stack frames into json ○ Render using d3-flame-graph ● No special environment ● No special steps ● Single button generation ● Can be used in production/dev/qa ● Exposes only javascript side of the code
  57. 57. Used For ...
  58. 58. ● CPU profiling ● Troubleshooting in production the problem at hand ● Memory leak investigation ● Regular sampling
  59. 59. Practice Fire Safety
  60. 60. Flame Graphs:
  61. 61. Tools > Waterfall Charts
  62. 62. ● Logs are hard to read ● Timestamps are hard to compare ● We need a faster tool?
  63. 63. Why not use the same method used by developer tools in browser?
  64. 64. Waterfall Charts
  65. 65. ● Requires code instrumentation ● Easy and quick to assess what is going on ● Easy to spot synchronous events ● Analyze for possible task parallelization
  66. 66. Lessons Learned
  67. 67. ● Latency, TCP_NODELAY=true ● Handling request close, finish, error events is important ● No dns cache out of the box ○ Use OS level caching to allow restarts ● Avoid modules with a state ● Embedding within App teams to bootstrap works great ● Use cold cache to keep restarts fast
  68. 68. Challenges
  69. 69. ● Version control ○ npm shrinkwrap does not guarantee versions ○ switched to Uber shrinkwrap ● App and platform coupling in one build ○ It is still monolithic, platform coupled to app ● Upgrading to major versions ○ Need to keep backwards compatible ○ Teams go at their own pace ● Memory leak analysis ● Debugging ○ Not stable, gets broken frequently
  70. 70. So Far So Good
  71. 71. What’s next?
  72. 72. ● 1 billion requests / day ● Decoupling platform from application ○ Moving platform components into separate processes ○ Independent platform deployments ○ More resilient apps ○ Problem isolation (easier memory leak detection) ● Platform microservices ● Docker ● Kubernetes ● SenecaJS ● NodeJS services
  73. 73. References • Progressive rendering: http://www.ebaytechblog.com/2014/12/08/async-fragments- rediscovering-progressive-html-rendering-with-marko • AMP: http://www.ebaytechblog.com/2016/06/30/browse-ebay-with-style-and-speed/ - sse between frontend and backend - streaming • http://www.ebaytechblog.com/2016/06/15/igniting-node-js-flames/ • http://www.ebaytechblog.com/2016/07/14/mastering-the-fire/ • http://www.slideshare.net/tcng3716/ebay-architecture • Cloud http://www.computerweekly.com/news/2240222899/Case-study-How-eBay-uses-its- own-OpenStack-private-cloud • http://www.ebaytechblog.com/2014/10/02/dont-build-pages-build-modules/ • history: http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf • lasso: https://www.npmjs.com/package/lasso • marko: http://markojs.com/ • https://github.com/spiermar/d3-flame-graph
  74. 74. Questions ?
  75. 75. Back slides

×