Download as PDF, PPTX
Uploaded byVMware Tanzu
Spring Cloud Gateway - Nate Schutta
Spring Cloud Gateway is a gateway that provides routing, filtering, and monitoring capabilities for microservices. It is non-blocking and built on Spring Framework and uses reactive streams. Spring Cloud Gateway offers a simpler and more developer-friendly alternative to other gateway options that are often heavy-weight and difficult to integrate. It provides a Java-based configuration that gives developers control over routing, filtering, and other gateway features without vendor lock-in.
More Related Content
Similar to Spring Cloud Gateway - Nate Schutta
Spring Cloud Gateway - Nate Schutta
- 1.
- 2.
- 3.
- 4. Kind of thein thing these days…
- 5. And everything thatentails!
- 6. Lot of teamsare adopting microservices…
- 7. Only to discoversome assembly required.
- 8. Think about allthe things a cloud native app needs…
- 9. Service registry. Circuitbreaker. Config server. UAA.
- 10.
- 11. And, often, anAPI gateway.
- 12. What would yousay that is?
- 13. Why would youneed one?
- 14. What are myoptions?
- 15. Why should Iconsider Spring Cloud Gateway?
- 16. Why do ineed A Gateway?
- 17.
- 18. It was asimpler time…
- 19.
- 20. What is ourtarget resolution?
- 21.
- 22. Well, we’d argue aboutsome things…
- 23.
- 25.
- 26. The Monolith (with aside of REST) The Browser HTTP Request Mobile Apps XML/JSON Res HTTP Request XML/JSON Res
- 27. You get anAPI, and *you* get and API, and YOU get an API!
- 31. What caused thisCambrian explosion of APIs?
- 32.
- 33. Reaction to monolithsand heavy weight services.
- 34. As well ascloud environments.
- 35.
- 36. But it didn’tstop there…
- 37.
- 38. The Monolith (with aside of REST) The Browser HTTP Request Mobile Apps XML/JSON Res HTTP Request XML/JSON Res
- 39.
- 40.
- 41.
- 42.
- 43. Shoot. What dowe do now?
- 44. More architectural patterns, moreproblems.
- 45. How do wefacilitate communication?
- 46.
- 47.
- 48.
- 49. Different clients needdifferent data!
- 50.
- 51. Backend for front-endvariation.
- 52. Each client getstheir own gateway.
- 53. Enter the APIGateway!
- 54.
- 55.
- 56. Gateways are not,in fact, magic sparkle ponies...
- 57.
- 59.
- 60. Isn’t this justan ESB?
- 61. Saw that movie…knowhow it ends.
- 62. The principles ofESB aren’t bad.
- 63. Potential to recreatethe worst of the ESB era…
- 64. Single point offailure.
- 65. Tickets on topof tickets. With a side of tickets. And more tickets.
- 66.
- 67.
- 68. Doesn’t have tobe that way!
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76. Even better -data driven strangler. https://content.pivotal.io/slides/strangling-the- monolith-with-a-data-driven-approach-a-case-study
- 77.
- 78.
- 79.
- 80.
- 81. Decouple clients fromendpoints.
- 82. End point peruse case.
- 83.
- 84. Rate limiting iseasy right?
- 85. It is justX requests per second.
- 86. How do youactually enforce it?
- 87. Is it onthe second boundary?
- 88. Straightforward on asingle process.
- 89. But most appsare distributed these days so…
- 90.
- 91. Two parameters: replenishrate and burst capacity.
- 93. Tap is dripping“tokens” into the bucket.
- 94. This is you’rereplenish rate.
- 95. Requests come andpull tokens out of the bucket.
- 96. If there areany!
- 97.
- 98. 429 Too ManyRequests. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
- 99. Burst capacity isthe size of the bucket.
- 100. How many tokenswill this bucket hold?
- 101. Could have moretokens than requests per second.
- 102. In other words,burst capacity is larger than the replenish rate.
- 103. Can have “rollovertokens!”
- 104. Good enough forStripe. https://stripe.com/blog/rate-limiters
- 105. Spring Cloud Gatewaybrings Stripe’s approach to you.
- 106. More on thatin a minute…
- 107.
- 108. What does areactive load balancer look like exactly?
- 109. Many strategies areno better than 2 random choices.
- 110. The Power of2. https://brooker.co.za/blog/2012/01/17/two-random.html
- 111. The Power ofTwo Choices in Randomized Load Balancing. https://www.eecs.harvard.edu/~michaelm/postscripts/tpds2001.pdf
- 112. Stale data leadsto herd behavior.
- 113. Host A isquiet… keep sending it traffic.
- 114. But now Ais overloaded.
- 115. The LB doesn’tknow it yet.
- 116. Next time itupdates the cache, A is overloaded…
- 117. So it goesquiet again.
- 118. Cycle back andforth. Quiet, busy, quiet, busy…
- 119. There is anotherway.
- 120.
- 121. Forward to theleast busy one.
- 122. Has the bestof both worlds.
- 123.
- 124. Doesn’t suffer from theherd behavior.
- 125.
- 126.
- 127.
- 129. Bit of agray area here…
- 130. The line isfuzzy.
- 131. Don’t sneak anybusiness logic into your gateway!
- 132. Often want tomodify the request/response…
- 133. Don’t recreate the worstof the ESB era.
- 134.
- 135. As you canguess, there is a veritable plethora of options.
- 136.
- 137. Can be hardwareor virtual.
- 138. Act as ablack box.
- 139.
- 140. F5, Apigee, CAAPI Gateway, etc.
- 141.
- 142. No management (foryou).
- 143.
- 144.
- 145. Can be verypricey.
- 146. AWS Elastic LoadBalancing, Apigee.
- 147. Work really well- when you are running on the same cloud!
- 148. But if youaren’t…
- 149.
- 150.
- 151.
- 152. Apache mod_proxy, Nginx Kong,HA Proxy
- 153. Can be programmable (oftenvia C or Lua).
- 154.
- 155.
- 156.
- 157. Service meshes arekind of all the rage these days.
- 158. Distinction between east/west andnorth/south routing.
- 159.
- 160. Think app toapp or app to service. Container to container.
- 161. All within thefamily.
- 162. North/south also calledingress.
- 163. External traffic callingyour services.
- 164. Aka from outsidethe family.
- 165. Meshes tend tobe oriented towards operations and platforms.
- 166. Very much “ops”,not so much dev ops.
- 167.
- 168. But no discussionwould be complete without mentioning…
- 169.
- 170. You know, the Gatekeeperof Gozer.
- 171. Came out ofNetflix.
- 172. No one couldhave predicted this.
- 173.
- 174.
- 175.
- 176.
- 177. No long livedconnections.
- 178. Clunky API, notoverly developer friendly.
- 179. Can be toughto integrate.
- 180.
- 181. Number of proprietaryfeatures.
- 182. Early part ofSpring Cloud.
- 183. Engineers at Netflixdon’t just sit around drinking espresso.
- 184.
- 185. Lessons learned fromZuul 1.
- 186. It is *not*backwards compatible.
- 187.
- 188. Originally written onRxNetty.
- 189. Rewritten to Nettyprimitives.
- 190.
- 191.
- 192.
- 193. Zuul 2 : TheNetflix Journey… https://medium.com/netflix-techblog/zuul-2-the-netflix-journey- to-asynchronous-non-blocking-systems-45947377fb5c
- 194.
- 195. Often very heavyweight.
- 196. Tickets on topof tickets. With a side of tickets. And more tickets.
- 197. Embodies the negativeconnotation of “enterprise software”.
- 198. It doesn’t haveto be this way…
- 199.
- 200. A Spring approachto the gateway problem!
- 201. Based on Spring5, Reactor and Boot 2.
- 202.
- 203.
- 204.
- 205.
- 206. Lives along sideSpring MVC.
- 207.
- 208.
- 209. HandlerMapping - whatcode is going to handle this request.
- 210. WebFilter - manipulatethe request/response.
- 211. Predicate - testsome aspect of the request…
- 212. And determine whetherto route it.
- 213. ServerWebExchange: access all partsof the http request/response.
- 214. Configure routes inJava, YAML or via repositories.
- 215. Can route onpath, host, headers, parameters…
- 216. Anything in therequest.
- 217.
- 218.
- 219. Add or removerequest/ response headers.
- 220.
- 221.
- 222. With so manyoptions, why should I use Spring Cloud Gateway?
- 223. It is programmercentric routing.
- 224. Antithesis of ticketswith a side of tickets. And more tickets.
- 225. Would you ratherrefresh a configuration?
- 226. Or fill outanother ticket?
- 227. Java centric, Springcentric.
- 228. You are incontrol.
- 229. Instead of oneof these…
- 231. You can craftyour own…
- 233. Except *you* decidewhat tools, blades etc. you want.
- 234.
- 235. Use it asyou will. You aren’t forced down a certain path.
- 236. Think of itas an ESB with inversion of control.
- 237. It is nota SaaS, it is a tool.
- 238. You can’t just“run” SC Gateway.
- 239. It is justan app.
- 240.
- 241. You know howto build and run applications.
- 242. You build it,you push it.
- 243. It is inyour hands, not some random enterprise group.
- 244. Anything you coulddo in Zuul 1 is supported in SC Gateway.
- 245. But what aboutperformance?
- 246. There was abenchmark published in December 2017.
- 247. SC Gateway wasnot officially released at that time.
- 248. There are noperformance issues today.
- 249. Many large companiesrely on it.
- 250.
- 251.
- 252.
- 253.
- 254. Route: basic building blockof the gateway.
- 255. ID, a destinationURI, a collection of predicates & a collection of filters.
- 256. If the aggregatepredicate is true, the route is matched.
- 257. Predicate: a Java8 Function Predicate. https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html
- 258. Allows you tomatch on anything from the HTTP request.
- 259. Filter: Instances Spring FrameworkGatewayFilter. https://cloud.spring.io/spring-cloud-gateway/single/ spring-cloud-gateway.html#_gatewayfilter_factories
- 260. Allows you tomodify requests and responses.
- 262.
- 264.
- 266.
- 268. Multiple Route Predicate Factoriescan be combined.
- 269.
- 270.
- 272.
- 274. The Hystrix filtercan also accept an optional fallbackUri parameter.
- 275.
- 277.
- 279.
- 280.
- 281. Add multiple filtersto Route.
- 282.
- 283.
- 284. WebSocket, Netty, GatewayMetrics.
- 285. You can mixand match.
- 286. Make it ascomplicated as you’d like!
- 287. Fluent Java RoutesAPI if you prefer programmatic approach.
- 288. Very powerful, veryuseful!
- 289. Microservices are auseful architectural pattern.
- 290. Like any designdecision, there are consequences.
- 291. But you knewthat ;)
- 292.
- 293. Doesn’t have todevolve into a blizzard of tickets!
- 294.
- 295. September 24–27, 2018 WashingtonDC Gaylord, National Harbor Discount Code S1P200_NSchutta Register Today & Save!
- 296. Nathaniel T. Schutta @ntschutta ntschutta.io Thanks! I’ma Software Architect, Now What? with Nate Shutta Modeling for Software Architects with Nate Shutta Presentation Patterns with Neal Ford & Nate Schutta