共计 2938 个字符，预计需要花费 8 分钟才能阅读完成。
单体架构
下图简略展现了单体架构的工作流程
单体架构是把所有的模块和性能集中到一起，部署到一台服务器中，这种一把梭的形式, 赢了还好，输了就下海干活。如果申请过大, 一台机器撑不住, 也只能通过增加机器的形式来进行横向扩大。
微服务架构
微服务架构中咱们的利用往往是拆分成不同的模块，取而代之的是多个不同的 Service 独立部署。他们之间的通信通过 http 或者 rpc 等形式，这样每个模块咱们就能够独立开发，互不影响。
能够看到之前的单体零碎提供的性能被咱们拆分成了很多个模块，别离部署成不同的服务。
手机端用户间接通过 Nginx 拜访不同的后端服务，然而在手机端须要实现聚合性能。比方首页须要显示的数据须要在不同的服务中获取数据，就须要将数据申请回来组合之后能力进行显示，所以个别咱们会在手机客户端和微服务之间减少一层。
这一层次要做什么呢？聚合数据之后返回对立格局的数据, 还能够依据不同设施类型进行裁剪(比方平板和手机显示就不一样), 因为减少了 BFF(backend for frontend，为前端开发的后端),APP 和后端 API 就解除了强耦合的关系，两边是能够独立变动的, 不会受到另一方影响。
有的服务返回的数据可能是 xml 格局，有的有可能是 json 格局
微服务看起来很棒，然而也存在一些挑战，在微服务架构之下，服务被拆的十分零散，升高了耦合度的同时也给服务的对立治理减少了难度。
在旧的服务治理体系之下，鉴权，限流，日志，监控等通用性能须要在每个服务中独自实现，这使得零碎维护者没有一个全局的视图来对立治理这些性能。而计算机的问题都能够通过减少一层来解决这个问题，所以咱们能够减少一层 API 网关来包容这些通用的性能，在此基础上提供零碎可扩展性。
能够看到这里又提出来了一层 gateway，而对于 BFF, 有些公司可能将其和 gateway 合并了，具体怎么解决，得看理论状况是怎么的了。
API 网关模式意味着你要把 API 网关放到你的微服务们的最前端，并且要让 API 网关变成由利用所发动的每个申请的入口。这样就能够显著的简化客户端实现和微服务应用程序之间的沟通形式。
没有网关之前, 客户端将商品退出购物车不得不去申请用户服务，而后再到商品服务，而后是购物车服务。客户端须要去晓得怎么去一起来生产这三个不同的 service。应用 API 网关，咱们能够形象所有这些复杂性，并创立客户端们能够应用的优化后的端点，并向那些模块们发出请求。
你还能够通过 API 网关中心化中间件的能力。当你开始创立越来越多的服务时，你会发现自己面临了一个新的问题 – 就是你发现你须要对一些服务进行身份验证和流量管制。
有的服务是 public 的；有的是 private 的；有的则是合作伙伴的 API，这些你只能提供给一些特定的用户。迟早你会发现自己在实现每个微服务时总是一次次的反复编写一些雷同的代码，这些代码其实都是能够形象为中间件的。
这显然不是每个微服务应该去关注的事件。API 网关才应该把这件事件揽下，也就是说微服务只负责接管进来的 request- 而后返回一个相似 JSON 格局的 response 即可。而后 API 网关就把这些例如身份验证、日志（logging）以及流量管制都归于麾下。
微服务并不都是长处, 它同样有一长串须要思考的问题，比方日志、监控、异样解决、容错、回滚、通信、音讯格局、容器、服务发现、备份、测试、报警、跟踪、工具、文档、扩大、时区、API 版本、网络提早、健康检查、负载平衡等等问题, 一个新的形式解决问题的同时也会面临新的问题，所以不要感觉微服务就肯定好，每个阶段面临的问题不一样, 咱们解决问题，对待问题的形式也不一样。
微服务要关怀的事件太多，所以如果你的公司筹备转成微服务就肯定要有具备这些解决微服务面临问题的能力。
云原生服务
微服务之后, 又衰亡了云原生服务, 什么是云原生服务呢？
云原生利用定义: 基于微服务原理而开发的利用，以容器形式打包。在运行时，容器由运行于云基础设施之上的平台 (比方 kubernetes) 进行调度。利用开发采纳继续交付和 DevOps 实际。
云原生服务还是离不开微服务，只是它是运行在具备云原生根底的平台中的，而且采纳的是继续交付和 DevOps 实际。这个云原生平台有什么作用呢？用过 Kubernetes 的都晓得它不必放心扩大、服务发现、负载平衡、容错、回滚、更新等等问题，并且对于 gateway, 监控等等都有配套的成熟解决方案。真的是谁用谁晓得。
这里就不开展说了，感兴趣的能够去理解下 Kubernetes
API Gateway 抉择
网关须要思考哪些内容
- 限流熔断
- 动静路由和负载平衡
- 基于 path 的路由, 比方 example.com/user 拜访问用户服务, example.com/shopping 拜访购物服务
- 截获器链
- 日志采集和 Metrics 埋点
- 响应流优化
- 可编程 API
- Header 头重写
各大网关比照
| 反对公司 | 实现语言 | 亮点 | 有余 | |
|---|---|---|---|---|
| Nginx(2004) | Nginx Inc | C/Lua | 高性能，成熟稳固 | 门槛高, 偏运维, 可编程弱 |
| Zuul1(2012) | Netflix/Pivotal | Java | 成熟, 简略门槛低 | 性能个别，可编程个别 |
| Spring Cloud Gateway(2016) | Pivotal | Java | 异步, 配置灵便 | 晚期产品 |
| Envoy(2016) | Lyft | C++ | 高性能, 可编程 API/ServiceMesh 集成 | 门槛较高 |
| Kong(2014) | Kong Inc | OpenResty/Lua | 高性能, 可编程 API | 门槛较高 |
| Traefik(2015) | Containous | Golang | 云原生, 可编程 API/ 对接各种服务发现 | 生产案例不太多 |
理论中咱们应用的是云原生服务, 而 Zuul 和 Spring Cloud Gateway 联合 Spring Cloud 全家桶联合应用成果较好，所以它不太适宜咱们当初的抉择。
咱们将眼光集中在 Kong 和 traefik 中, 通过比照发现, 咱们最终还是抉择了 traefik, 相比拟于 Kong,traefic 的劣势如下:
1. traefik 较为轻量，十分易于应用和设置
2. traefic 通过 Kubernetes 存储状态(Kong 要应用 Postgres 或者 Cassandra 来存储状态)，并利用 Ingress 通过 https 将所有流量路由到对应的服务
3. 已在寰球范畴内用户生产环境，并通过了严格的测试和基准测试，在我司其余我的项目中有使用
4. Kong 仪表板，它是独自开发的，与最新版本的 Kong 兼容须要花点工夫。Traefik 带有本人的仪表板，它始终与最新的 Traefik 版本兼容,Traefik 的用户界面也比 Kong 的用户界面难看。
traefik 的 Middlewares 真心好用,traefik 倡议降级到 traefik2
并且 traefik 还能够作为 Kubernetes ingress controller, 能够齐全代替咱们之前说过的 nginx controller
如何应用 traefick 作为网关进行用户验证
ingress route 的配置：
代码:
通过下面的配置之后，当咱们想要拜访 /api/orders 这个 api 的时候就会先去 /api/auth 中进行受权验证用户是否登录，如果登录后则会将携带对应的 http header 到对应的后端服务，后端服务在依据这个 header 进行验证
