API-Gateway

前言 伴随着随着微服务概念的不断盛行，与之对应的各种解决方案也层出不穷。这毕竟是一个信息大爆发的时代，各种编程语言大行其道，各有各的优势。但是有一点未曾改变，那就是他们服务的方式，工作的时候各司其职，但是需要提供服务的时候必须要高度统一，这也是微服务的概念之一。日常的工作学习中，我个人更喜欢通用的解决方案，特别是能将不同编程语言亦或者不同编程框架整合到一起的那种，这种解决方案拉近了编程语言之间的距离，让开发者能更清楚的意识到编程语言只是工具，解决问题才是王道。好了口遁到此结束，接下来我就搭建一套.Net体系结合Java体系的项目架构。 概念介绍 接下来我们用到的技术栈名词主要涉及到ASP.NET Core、Nacos、Spring Cloud Gateway,接下来我们分别介绍所使用的的三种框架。 Nacos Nacos是阿里巴巴开源的致力于服务发现、配置和管理微服务的框架。提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。一般用到的最多的就是当做配置中心和注册中心。 中文官网地址： https://nacos.io/zh-cn/ 官方 GayHub GitHub地址： https://github.com/alibaba/nacos 下载地址： https://github.com/alibaba/nacos/releases

　　笔者十年前做过网络游戏，当第一次看到微服务架构就发现它和网络游戏架构很像，如下图： 　　 　　先来简单介绍一下这个网游架构，有些东西记不清了，如今的网游大牛看到可别丢砖头。 用户下载网游客户端，登录网游，首先会执行登录服务，登录服务主要就是给你分配一个网关，因为网关后面连接的才是真正的游戏服务器。登录后，进入游戏，发出指令，比如你移动到某个位置，这个指令会先发送到网关，然后再由网关识别发送到“移动系统”服务，移动系统计算后再经由网关发送给玩家客户端，玩家客户端执行一个动画让你移动到某个位置。 假如子服务间要通信也是通过网关转发，比如任务系统里面要购买物品，那么任务系统发一个指令消息给网关，网关再转发给物品系统等等。图中的“游戏A服务器集群”，其中“游戏A”代表你所属的游戏服务器，每个游戏服务器能承载的人数是有限的（当时的技术一个服务器组最多同时在线也就几千人），人数满了，你就要登录到另外的服务器。“集群”表示服务部署的集群。每一个明面上的游戏服务器，对应一个N台服务器构成的游戏服务集群，但只对应一个用户数据库，数据库没有使用集群技术，因为你即使使用了数据库集群技术，在实时性方面也跟不上。 从编程上来讲，包括以下应用： 客户端.exe 网关.exe 移动系统.exe 聊天系统.exe …. 说到这里，了解微服务的人可能看出来了，上面的网关就好比nginx反向代理服务器

组件概述 以下是组件图 图片来源于： 此处 Kubernetes采用Master/Slave架构，主要包含如下组件： Master组件包含 API Server:API Gateway,用于和所有的组件进行交互的节点； Controller Manager:业务逻辑的控制中⼼，包含各类控制器模块 Scheduler: 对Pod进行实际调度 ETCD: 用于存储所有Kubernetes的元数据，KV存储 Slave组件 Kubelet: Node和Pod⽣生命周期管理 Kube-Proxy: Pod的对外服务发现代理 cAdvisor:容器监控，目前集成到了kubelet组件中 一般通过kubectl提交命令，然后通过APIServer存储到ETCD，再由各个组件进行watch并做相关处理。 核心资源大图 Pod: 一组容器，是kubernetes系统中的最⼩的调度单元，是直接处理业务的Workload； 应⽤用配置: ConfigMap: 可以存储相关的应用配置信息； Secret: 一般用于存储应用的秘钥信息，通过base64进行编码； PVC: 应用的持久化存储； 应⽤用服务发现: Service: Pod对外服务的负载均衡 Endpoints: 和Service⼀一⼀一对应，表示Pods的IP/Port信息 相关控制器: Deployment : 用于无状态应用的生命周期管理

微服务的概念虽然直观易懂，但“细节是魔鬼”，微服务在实操落地的环节中存在诸多挑战。我们在为企业提供PaaS、人工智能、云原生平台等数字化转型解决方案时也发现，企业实现云原生，并充分利用PaaS能力的第一步，往往是对已有应用架构进行现代化微服务改造，而如何进行微服务拆分、设计微服务逻辑、实现微服务治理等实操问题成为很大的挑战。 本文既包含了微服务的原理、原则，又包含了实际落地中的架构设计模式；既包含可举一反三的理念和概念，也包含类似领域驱动设计、Saga实现事务操作、CQRS构建事件驱动系统等具体可套用的示例。本书可以帮助读者把传统的单体巨石型应用循序渐进地改造为微服务架构，从微服务的拆分，微服务架构下业务逻辑的设计以及事务、API、 通信等的实现，一直到微服务系统的测试与生产上线，帮助读者建立从无到有的完整微服务系统搭建的生命周期。 书籍优质内容节选 第8章外部APl模式 8.1外部API的设计难题 为了探索与API相关的各种问题，让我们考虑一下FTGO应用程序。如图8-1所示,该应用程序的服务由各种客户端使用。使用服务API的客户端一共有四种: ■Web应用程序，如Consumer web 应用程序一为 消费者实现基于浏览器的用户界面，Restaurant web 应用程序一实 现基于浏览器的餐馆用户界面，以及AdminWeb应用程序一实 现供内部管理员使用的用户界面。

没有 web 接口开发经验，只会简单写一写功能函数，有没有办法写一个收集客户端数据的接口呢？本文将一步步带你如何在没有接口开发经验的情况下轻松的使用 AWS 服务器服务构建自己定制化的 API 接口。 一、前期准备 1.1、业务需求 假设 T 公司有一个全球性的网站，每个国家站点都有一个下载页面。公司想要去监测全球用户的下载情况，需要对下载按钮进行埋点，那我们就需要有一个接口可以监测到用户的下载情况，需要记录的数据有如下： country：用户来自哪个国家 create_time：下载时间 ip：用户的 IP referer：从哪个页面下载的 site：国家站点代码 我们不可能针对每个站点都做一个链接作为借口，最好的方式就是创建一个链接，通过传递不同的参数来埋到不同的下载按钮，链接类似下面结构： https://down.wzlinux.com?type=CN https://down.wzlinux.com?type=US https://down.wzlinux.com?type=IN 1.2、解决方案 看到这个需求，一个专业的开发人员可能很快可以解决，需要较高的开发技能，还需要运维购买服务器，部署等，相对来说比较麻烦，并且管理起来相对复杂。本文所展示的就是你只会简单的功能函数开发即可完成这个需求的开发部署，而且全部使用 AWS 的无服务器组件，用户不需要再关系底层硬件

API 网关结合云函数 SCF 的使用场景非常丰富，本文将介绍如何基于 API 网关+云函数 SCF 快速部署 Serverless 的外卖订单系统。 消息推送使用的典型场景 外卖订单系统架构图 Demo 实战 1. 安装Serverless Framework npm install -g serverless 2. 初始化项目模板 sls init -t websocket-order 3. 查看项目目录 下载到本地后，查看项目目录结构如下： 包含 DB、网关、函数等多个子模块。 db 目录用于创建 PG Serverless 数据库实例 apigateway 用于创建对应的 API ： /bill 下单 API，HTTP 类型 /get_shop_info，获取店铺菜单 API /pgws，用于做消息推送的 websocket API 函数列表如下： 消息推送相关函数： 注册函数 ws_register.py， 配置 DB 的环境变量 传输函数 ws_trans.py ，配置 DB 的环境变量以及 apiid= 消息推送API 注销函数 ws_unregister.py ，配置 DB 的环境变量以及 apiid= 消息推送API 下单函数 bill.py ， 配置 DB 的环境变量以及 apiid= 消息推送API 拉取店铺信息函数 get_shop_info.py，配置

本篇已加入《 .NET Core on K8S学习实践系列文章索引 》，可以点击查看更多容器化技术相关系列文章。 上一篇 介绍了Ingress的基本概念和Nginx Ingress的基本配置和使用，考虑到很多团队都在使用Ocelot作为API网关（包括我司）做了很多限流和鉴权的工作，因此本篇介绍一下如何使用Ocelot接入替代Nginx Ingress作为统一入口。 一、准备工作 　　我们仍然以上一篇的两个ASP.NET Core WebAPI示例作为K8s集群中的后端服务示例，这里我们来快速地准备一个基于Ocelot的API网关服务。 　　至于怎么创建Ocelot API网关，已经有很多文章介绍了，这里就不再赘述。需要注意的步骤有以下几点： 　　（1）根据Ocelot的版本引入匹配的K8s Provider： 　　可以看到，这个Provider包是 张队 写的，目前已经支持.NET Core 3.1，最新版本是15.0.6。这里我选择的是13.5.2，因为我的API网关服务还是.NET Core 2.2的版本。 KubeClient是kubernetes 的C#语言客户端简单易用，KubeClient是.NET Core（目标netstandard1.4）的可扩展Kubernetes API客户端， github地址 点击这里

在去年的 .NET Core微服务系列文章 中，初步学习了一下Consul服务发现，总结了 两篇文章 。本次基于Docker部署的方式，以一个Demo示例来搭建一个Consul的示例集群，最后给出一个HA的架构示范，也会更加贴近于实际应用环境。 一、示例整体架构 　　此示例会由一个API Gateway, 一个Consul Client以及三个Consul Server组成，有关Consul的Client和Server这两种模式的Agent的背景知识，请移步我之前的文章加以了解：《 .NET Core微服务之基于Consul实现服务治理 》。其中，Consul的Client和Server节点共同构成一个Data Center，而API Gateway则从Consul中获取到服务的IP和端口号，并返回给服务消费者。这里的API Gateway是基于Ocelot来实现的，它不是这里的重点，也就不过多说明了，不了解的朋友请移步我的另一篇：《 .NET Core微服务之基于Ocelot实现API网关服务 》。 二、Consul集群搭建 2.1 Consul镜像拉取 docker pull consul:1.4.4 　　验证：docker images 　　 2.2 Consul Server实例创建 　　以下我的实践是在一台机器上（CentOS 7）操作的

是不是现在每个团队都需要上K8s才够潮流，不用K8s是不是就落伍了。今天，我就通过这篇文章来回答一下。 一、先给出我的看法和建议 我想说的是，对于很多的微小团队来说，可能都不是一定要上K8s，毕竟上K8s也是需要成本和人力的。对像我司一样的传统企业做数字化转型的信息团队来讲，人数不多，没有专门的Ops人员，领导又想要尽快迭代支持公司业务发展，而且关键还要节省成本（内心想法是： WTF ）。 在此之下，信息团队需要综合引入先进技术带来的价值以及需要承担的成本和风险。任何架构的产生，都会解决一定的问题，但是同样也会引入新的复杂度，正如微服务架构风格，看着香实际吃着才知道需要承受很多的“苦”（比如数据一致性又比如服务的治理等等）。 因此，结合考虑下来，我的建议是 开发测试环境使用Docker Compose进行容器编排即可，而UAT或生产环境则建议使用云厂商的K8s服务（比如阿里云ACK服务）而不选择自建K8s集群 。 那么，今天就跟大家介绍一下如何使用Docker Compose这个轻量级的编排工具实现.NET Core微服务的持续发布。 二、Docker Compose Docker主要用来运行单容器应用，而Docker Compose则是一个用来定义和应用多容器应用的工具，如下图所示： 使用Docker Compose，我们可以将多容器的定义和部署方式定义在一个yml文件中

在去年的 .NET Core微服务系列文章 中，初步学习了一下Consul服务发现，总结了 两篇文章 。本次基于Docker部署的方式，以一个Demo示例来搭建一个Consul的示例集群，最后给出一个HA的架构示范，也会更加贴近于实际应用环境。 一、示例整体架构 　　此示例会由一个API Gateway, 一个Consul Client以及三个Consul Server组成，有关Consul的Client和Server这两种模式的Agent的背景知识，请移步我之前的文章加以了解：《 .NET Core微服务之基于Consul实现服务治理 》。其中，Consul的Client和Server节点共同构成一个Data Center，而API Gateway则从Consul中获取到服务的IP和端口号，并返回给服务消费者。这里的API Gateway是基于Ocelot来实现的，它不是这里的重点，也就不过多说明了，不了解的朋友请移步我的另一篇：《 .NET Core微服务之基于Ocelot实现API网关服务 》。 二、Consul集群搭建 2.1 Consul镜像拉取 docker pull consul:1.4.4 　　验证：docker images 　　 2.2 Consul Server实例创建 　　以下我的实践是在一台机器上（CentOS 7）操作的