API-Gateway

作者： Java的小本家 链接： http://suo.im/6nKkAo 一、API网关的用处 API网关我的分析中会用到以下三种场景。 Open API 企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。 微服务网关 微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。 API服务管理平台 上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。 API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。 二

目录 0:00 微服务与网关（Microservices & API Gateways） 大家好，我叫Macro，今天我们谈论有关微服务和网关的话题。我是Mashape的CTO,也同时是开源网关Kong的开发者之一。Kong是一个API网关，今天我们就来窥探一下它究竟是怎么工作的以及它如何运用到你的微服务架构中去。 0:23 主题（Topics） 为了明白我们为什么需要API网关，我将从单体架构vs微服务架构谈起。这两个有什么不同点呢？然后我会介绍API网关模式以及它是如何适应“面向微服务”的架构的。然后我们会讨论Kong以及NGINX。 0:47 单体架构（Monolithic Architecture） Ok，过去几年我们目睹的一件事就是从单体应用到面向微服务的架构的过渡。我们都熟悉单体应用程序，以及它们通常的工作原理，这是一个简单的展示。我们把所有的东西都放到一块。而且通常也只有一个数据存储。 通过在多个服务器上重复部署相同的巨大代码块，可以横向扩展单体应用程序。所以每次我们调整应用程序时，我们其实相当于是在改动这些被放在一起的所有的模块，因为他们是一体的。 1:45 单体应用的优缺点（Monolithic Application Pros and Cons） 每一种做法，都有利弊。单体应用程序可以比较容易地构建，而且是以更小的代码库来开始

讲师 | 邹俊 | NGINX大中华区架构师 长期从事软件开发和系统架构设计工作，在企业级软件领域拥有超过10年的工作经验。先后供职于CA，EMC，Pivotal等公司。在十多年的软件行业从业经历中，积累了丰富的容器云平台架构设计、自动化平台运维和系统稳定性调优等相关经验，主要关注于微服务、APIM、k8s、service mesh等行业技术的发展。 在我们去年结束的4场NGINX功能场景的公开课中，我们已经向大家介绍了NGINX作为4/7层负载均衡、反向代理、静态内容缓存、API网关以及KIC等使用的典型功能场景了。 在接下来的系列讲座中，我们将继续带领大家从管理平面和应用的视角来探讨NGINX的使用场景，并进行更深入的了解。 NGINX服务网格解决方案 （1月 27日｜下午2:00-3:00 ） ►服务网格是什么 ►服务网格的演进 ►NGINX Service Mesh架构 ►NGINX Service Mesh的独特之处 K8s应用安全的威胁和防护 （2月24日 ｜下午2:00-3:00 ） ►容器应用面临的安全威胁和风险 ►容器应用的安全加固与防护 ►容器应用安全防护Demo NGINX Controller 之API管理解决方案 （3月24日｜下午2:00-3:00 ） ►API Gateway与API管理的对比 ►API管理的使用用例 ►API管理参考架构 ►API管理

点击上方 “ 方志朋 ”， 选择“置顶或者星标” 你的关注意义重大！ 微服务架构是一个庞大复杂的工程，为什么说它庞大复杂呢？因为想要做好微服务，就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章 《架构设计之「 微服务入门 」》 中已经初步介绍过了这些组件，包括：服务注册、服务网关、配置中心、服务框架、服务监控、服务追踪、服务治理等。 只有将这些基础设施搭建完善了，微服务实践的道路才能走的稳、走的远。后面的文章中会依次把每一个基础组件都详细分析一下。今天我们就先挑选「 服务注册 」聊一聊。 一、为什么需要「 服务注册 」？ 我们先来举一个生活中的例子：在以前互联网还不够发达的时候，“114号码百事通”大家应该很熟悉，有啥需求就会去打个电话查询一下。比如想知道附近电影院电话是多少，就会先去打114问一下。那114为啥知道这么多信息呢，还不是因为各类服务者（商店、机构等）都已经在114上登记了嘛。所以这里的“114百事通”就相当于一个服务注册中心了，这里的各类商店机构就相当于可以提供不同服务的服务者了，而打电话的我们就是去寻找这些服务的消费者了。 我们再来回到微服务架构中，一般集群都会部署很多个微服务节点。这些节点一般也具备这2种角色，称为：“服务的提供者” 和 “服务的消费者”。 “服务消费者”需要调用“服务提供者”的API来获得服务。当“服务提供者

一、MSA简介 1.1、MSA是什么 微服务架构MSA是Microservice Architecture的简称，它是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相通讯、互相配合，为用户提供最终价值。 它与SOA之间的区别如下： SOA实现 微服务架构实现 企业级，自顶向下开展实施 团队级，自底向上开展实施 粒度大：服务由多个子系统组成 粒度细：一个系统被拆分成多个服务，且服务的定义更加清晰 重ESB：企业服务总线，集中式的服务架构 轻网关：无集中式总线，松散的服务架构 开发过程复杂 易开发：减少了企业ESB开发的复杂性，与敏捷开发的思想高度结合在一起 单块架构系统，相互依赖，部署复杂 服务能被独立部署 1.2、我们的MSA框架 我们的 微服务框架MsaFx.dll 是个基于ServiceStack 4.0.60包装实现的.NET Web Services框架，而ServiceStack本身支持通用的轻量级协议和Metadata。 MsaFx 与普通 Web S ervices框架如WCF相比，主要优势如下 ： 1、 高性能： 性能好、速度快。 2、 支持跨平台运行： 基于M saFx 开发出的Web Services既能够运行在Windows环境中，又能够运行在支持Mono的Linux环境中。 3、 支持多协议： 如 JSON格式的也支持XSD。 4、