Spring Cloud Gateway - Nate Schutta
•
5 likes•1,496 views
Spring Cloud Gateway- Nate Schutta
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Spring Cloud Gateway - Nate Schutta
Similar to Spring Cloud Gateway - Nate Schutta (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
Spring Cloud Gateway - Nate Schutta
- 4. Kind of the in thing these days…
- 5. And everything that entails!
- 6. Lot of teams are adopting microservices…
- 7. Only to discover some assembly required.
- 8. Think about all the things a cloud native app needs…
- 9. Service registry. Circuit breaker. Config server. UAA.
- 11. And, often, an API gateway.
- 12. What would you say that is?
- 13. Why would you need one?
- 14. What are my options?
- 15. Why should I consider Spring Cloud Gateway?
- 16. Why do i need A Gateway?
- 18. It was a simpler time…
- 19. The Monolith The Browser HTTP Request HTTP Response
- 20. What is our target resolution?
- 21. Away we went!
- 22. Well, we’d argue about some things…
- 25. The Monolith The Browser HTTP Request HTTP Response
- 26. The Monolith (with a side of REST) The Browser HTTP Request Mobile Apps XML/JSON Res HTTP Request XML/JSON Res
- 27. You get an API, and *you* get and API, and YOU get an API!
- 31. What caused this Cambrian explosion of APIs?
- 33. Reaction to monoliths and heavy weight services.
- 34. As well as cloud environments.
- 36. But it didn’t stop there…
- 38. The Monolith (with a side of REST) The Browser HTTP Request Mobile Apps XML/JSON Res HTTP Request XML/JSON Res
- 40. Before you know it…
- 43. Shoot. What do we do now?
- 44. More architectural patterns, more problems.
- 45. How do we facilitate communication?
- 47. Forces.
- 49. Different clients need different data!
- 51. Backend for front-end variation.
- 52. Each client gets their own gateway.
- 53. Enter the API Gateway!
- 55. The Browser Mobile Apps Microservice Microservice Microservice Microservice Microservice APIGateway
- 56. Gateways are not, in fact, magic sparkle ponies...
- 59. Use them wisely.
- 60. Isn’t this just an ESB?
- 61. Saw that movie…know how it ends.
- 62. The principles of ESB aren’t bad.
- 63. Potential to recreate the worst of the ESB era…
- 64. Single point of failure.
- 65. Tickets on top of tickets. With a side of tickets. And more tickets.
- 67. Feature bloat.
- 68. Doesn’t have to be that way!
- 69. Just a tool.
- 70. Gateway Features
- 71. Routing.
- 73. Canarying.
- 74. Resiliency.
- 76. Even better - data driven strangler. https://content.pivotal.io/slides/strangling-the- monolith-with-a-data-driven-approach-a-case-study
- 77. Security.
- 78. Monitoring.
- 79. Metrics.
- 80. Flexibility.
- 81. Decouple clients from endpoints.
- 82. End point per use case.
- 83. Rate limiting.
- 84. Rate limiting is easy right?
- 85. It is just X requests per second.
- 86. How do you actually enforce it?
- 87. Is it on the second boundary?
- 88. Straightforward on a single process.
- 89. But most apps are distributed these days so…
- 91. Two parameters: replenish rate and burst capacity.
- 93. Tap is dripping “tokens” into the bucket.
- 94. This is you’re replenish rate.
- 95. Requests come and pull tokens out of the bucket.
- 96. If there are any!
- 97. If not?
- 98. 429 Too Many Requests. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
- 99. Burst capacity is the size of the bucket.
- 100. How many tokens will this bucket hold?
- 101. Could have more tokens than requests per second.
- 102. In other words, burst capacity is larger than the replenish rate.
- 103. Can have “rollover tokens!”
- 104. Good enough for Stripe. https://stripe.com/blog/rate-limiters
- 105. Spring Cloud Gateway brings Stripe’s approach to you.
- 106. More on that in a minute…
- 107. Load balancing.
- 108. What does a reactive load balancer look like exactly?
- 109. Many strategies are no better than 2 random choices.
- 110. The Power of 2. https://brooker.co.za/blog/2012/01/17/two-random.html
- 111. The Power of Two Choices in Randomized Load Balancing. https://www.eecs.harvard.edu/~michaelm/postscripts/tpds2001.pdf
- 112. Stale data leads to herd behavior.
- 113. Host A is quiet… keep sending it traffic.
- 114. But now A is overloaded.
- 115. The LB doesn’t know it yet.
- 116. Next time it updates the cache, A is overloaded…
- 117. So it goes quiet again.
- 118. Cycle back and forth. Quiet, busy, quiet, busy…
- 119. There is another way.
- 120. Pick two hosts.
- 121. Forward to the least busy one.
- 122. Has the best of both worlds.
- 123. Uses current data.
- 124. Doesn’t suffer from the herd behavior.
- 125. Throttling.
- 126. Request aggregation…
- 127. The list goes on!
- 129. Bit of a gray area here…
- 130. The line is fuzzy.
- 131. Don’t sneak any business logic into your gateway!
- 132. Often want to modify the request/response…
- 133. Don’t recreate the worst of the ESB era.
- 134. Options
- 135. As you can guess, there is a veritable plethora of options.
- 136. Appliances.
- 137. Can be hardware or virtual.
- 138. Act as a black box.
- 139. Low level.
- 140. F5, Apigee, CA API Gateway, etc.
- 141. SaaS solutions.
- 142. No management (for you).
- 143. Black box.
- 144. API driven.
- 145. Can be very pricey.
- 146. AWS Elastic Load Balancing, Apigee.
- 147. Work really well - when you are running on the same cloud!
- 148. But if you aren’t…
- 149. Web Server.
- 151. Reliable, proven.
- 152. Apache mod_proxy, Nginx Kong, HA Proxy
- 153. Can be programmable (often via C or Lua).
- 154. Service Mesh.
- 157. Service meshes are kind of all the rage these days.
- 158. Distinction between east/west and north/south routing.
- 160. Think app to app or app to service. Container to container.
- 161. All within the family.
- 162. North/south also called ingress.
- 163. External traffic calling your services.
- 164. Aka from outside the family.
- 165. Meshes tend to be oriented towards operations and platforms.
- 166. Very much “ops”, not so much dev ops.
- 168. But no discussion would be complete without mentioning…
- 169. Zuul.
- 170. You know, the Gatekeeper of Gozer.
- 171. Came out of Netflix.
- 172. No one could have predicted this.
- 174. Servlet based.
- 175. Blocking API.
- 176. Servlet 2.5 I/O.
- 177. No long lived connections.
- 178. Clunky API, not overly developer friendly.
- 179. Can be tough to integrate.
- 180. Path based routing.
- 181. Number of proprietary features.
- 182. Early part of Spring Cloud.
- 183. Engineers at Netflix don’t just sit around drinking espresso.
- 184. Zuul 2.
- 185. Lessons learned from Zuul 1.
- 186. It is *not* backwards compatible.
- 187. Non blocking I/O.
- 188. Originally written on RxNetty.
- 189. Rewritten to Netty primitives.
- 190. Supports HTTP/2.
- 193. Zuul 2 : The Netflix Journey… https://medium.com/netflix-techblog/zuul-2-the-netflix-journey- to-asynchronous-non-blocking-systems-45947377fb5c
- 194. Many, many options.
- 195. Often very heavy weight.
- 196. Tickets on top of tickets. With a side of tickets. And more tickets.
- 197. Embodies the negative connotation of “enterprise software”.
- 198. It doesn’t have to be this way…
- 199. SC Gateway
- 200. A Spring approach to the gateway problem!
- 201. Based on Spring 5, Reactor and Boot 2.
- 202. Non blocking IO.
- 203. Backpressure.
- 204. Event loop!
- 205. Spring WebFlux.
- 206. Lives along side Spring MVC.
- 208. Streams!
- 209. HandlerMapping - what code is going to handle this request.
- 210. WebFilter - manipulate the request/response.
- 211. Predicate - test some aspect of the request…
- 212. And determine whether to route it.
- 213. ServerWebExchange: access all parts of the http request/response.
- 214. Configure routes in Java, YAML or via repositories.
- 215. Can route on path, host, headers, parameters…
- 216. Anything in the request.
- 217. Filters!
- 218. Rewrite path.
- 219. Add or remove request/ response headers.
- 220. Rate limiting.
- 221. Hystrix.
- 222. With so many options, why should I use Spring Cloud Gateway?
- 223. It is programmer centric routing.
- 224. Antithesis of tickets with a side of tickets. And more tickets.
- 225. Would you rather refresh a configuration?
- 226. Or fill out another ticket?
- 227. Java centric, Spring centric.
- 228. You are in control.
- 229. Instead of one of these…
- 231. You can craft your own…
- 233. Except *you* decide what tools, blades etc. you want.
- 234. Lightweight, simple.
- 235. Use it as you will. You aren’t forced down a certain path.
- 236. Think of it as an ESB with inversion of control.
- 237. It is not a SaaS, it is a tool.
- 238. You can’t just “run” SC Gateway.
- 239. It is just an app.
- 240. Developer focussed.
- 241. You know how to build and run applications.
- 242. You build it, you push it.
- 243. It is in your hands, not some random enterprise group.
- 244. Anything you could do in Zuul 1 is supported in SC Gateway.
- 245. But what about performance?
- 246. There was a benchmark published in December 2017.
- 247. SC Gateway was not officially released at that time.
- 248. There are no performance issues today.
- 249. Many large companies rely on it.
- 250. Examples
- 251. Easy to add.
- 254. Route: basic building block of the gateway.
- 255. ID, a destination URI, a collection of predicates & a collection of filters.
- 256. If the aggregate predicate is true, the route is matched.
- 257. Predicate: a Java 8 Function Predicate. https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html
- 258. Allows you to match on anything from the HTTP request.
- 259. Filter: Instances Spring Framework GatewayFilter. https://cloud.spring.io/spring-cloud-gateway/single/ spring-cloud-gateway.html#_gatewayfilter_factories
- 260. Allows you to modify requests and responses.
- 262. After predicate.
- 264. Cookies!
- 268. Multiple Route Predicate Factories can be combined.
- 269. Logical and.
- 274. The Hystrix filter can also accept an optional fallbackUri parameter.
- 281. Add multiple filters to Route.
- 282. Global filters.
- 284. WebSocket, Netty, Gateway Metrics.
- 285. You can mix and match.
- 286. Make it as complicated as you’d like!
- 287. Fluent Java Routes API if you prefer programmatic approach.
- 288. Very powerful, very useful!
- 289. Microservices are a useful architectural pattern.
- 290. Like any design decision, there are consequences.
- 291. But you knew that ;)
- 292. Gateways are useful.
- 293. Doesn’t have to devolve into a blizzard of tickets!
- 294. Good luck!
- 295. September 24–27, 2018 Washington DC Gaylord, National Harbor Discount Code S1P200_NSchutta Register Today & Save!
- 296. Nathaniel T. Schutta @ntschutta ntschutta.io Thanks! I’m a Software Architect, Now What? with Nate Shutta Modeling for Software Architects with Nate Shutta Presentation Patterns with Neal Ford & Nate Schutta