API-Gateway

1. 导语 近期公司孵化了一个互联网产品，随着业务发展，产品运营后用户数据量（过亿）、业务数据量（过100亿）较大，技术团队配合产品、运营快速定制化开发， 还要考虑产品涉及的资金安全、消息的及时性、业务的制动化处理，我们选择鸿鹄cloud分布式云架构平台作为公司产品核心企业架构。 2. 产品平台规划 微服务注册中心（分布式集群部署）、微服务配置中心（分布式集群部署）、服务网关平台（分布式集群部署）、 微服务监控平台、SSO单点登录平台（分布式集群部署）、微服务相关组件（分布式集群部署）、后台管理平台、 定时调度平台（按照业务分库、分表部署）、业务微服务（分布式集群部署、超过20个微服务）、MQ消息中间件业务平台（分布式集群部署） MySql主从、读写分离（高可用部署）、Redis分布式缓存（高可用） 3. 源码结构： commonservice 通用服务：对spring Cloud组件的使用&封装，是一套完整的针对于分布式微服务云架构的解决方案 Component 通用组件：对系统常用组件的封装，包括对象存储包、工具包、缓存包、MQ相关、API调用包的封装等。 SAAS微服务 SAAS服务：针对通用业务如：会员、消息、支付等 快速开发管理平台 企业级快速开发平台，封装了用户、角色、权限、数据字典、菜单、日志、机构、部门等管理功能，针对于业务服务做了统一管理。 4. 分布式、微服务

　　1.路由前一个章节我们已经介绍过Ocelot，相信大家也了解到，Ocelot的主要功能是接收客户端等传入的HTTP请求，并将其转发到下游服务。Ocelot当前仅以另一个http请求的形式支持此功能(将来可能是任何传输机制)。 　　Ocelot将一个请求路由到另一个请求。为了让Ocelot正常工作，您需要在配置中设置一个Route。下面我们就Ocelot基础项目构建简单介绍下路由功能。 　　2.Ocelot基础项目构建(APIGatewayBasicDemo)现在我们根据GitHub贡献者开源项目来学习Ocelot，根据下载下来Ocelot基础项目结构来看，我们能看到有一个网关项目(APIGateway)，一个客户API项目(CustomersAPIServices)，一个产品API项目(ProductsAPIServices)。如下图所示： 　　 　　2.1Ocelot网关配置APIGateway网关项目根目录下面有一个configuration.json配置文件，内容如下： 　　 　　{ 　　//ReRoutes:处理上游请求的对象(客户端)，每个数组{}就是配置：上游地址和对应下游地址 　　"ReRoutes": [ 　　{ 　　//以Downstream开头的，是要转发到下游服务器的地址(CustomersAPIServices)，与nginx转发类似 　　/

Envoy为什么能战胜Ngnix——线程模型分析篇 导读：随着Service Mesh在最近一年的流行，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。作者是Envoy的开发者之一，本文详细说明了Envoy的线程模型，对于理解Envoy如何工作非常有帮助。内容较为深入，建议细细品读。 关于Envoy的基础技术文档目前相当少。为了改善这一点，我正在计划做一系列关于Envoy各个子系统的文章。 这是第一篇文章，请让我知道你的想法以及你希望涵盖的其他主题。最常见的问题之一是对Envoy使用的线程模型进行描述。 本文将介绍Envoy如何将连接映射到线程，以及Envoy内部使用的线程本地存储（TLS）系统，正是因为该系统的存在才可以保证Envoy以高度并行的方式运行并且保证高性能。 线程概述 图1：线程概述 Envoy使用三种不同类型的线程，如图1所示。 Main：此线程可以启动和关闭服务器。负责所有xDS API处理（包括DNS ， 运行状况检查和常规集群管理 ）， 运行时 ，统计刷新，管理和一般进程管理（信号， 热启动等）。 在这个线程上发生的一切都是异步的和“非阻塞的”。通常，主线程负责所有不需要消耗大量CPU就可以完成的关键功能。 这可以保证大多数管理代码都是以单线程运行的。 Worker：默认情况下，Envoy为系统中的每个硬件线程生成一个工作线程。（可以通过-

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

​转载本文需注明出处：微信公众号EAWorld，违者必究。 作为企业数字化中台建设支撑的技术中台，其前台是企业应用，后台是企业基础设施（网络、存储、计算等资源），可为企业数字化中台建设提供标准化、端到端、柔性（可变化）的软件生产能力，从而提升企业IT系统建设的效率与可用性。本文节选《金融企业数字化中台》部分内容，重点介绍如何建设技术中台。 技术中台建设的范畴 汽车制造的全生命周期对应到软件系统： 部件包括几种类型：业务组件、集成组件、技术组件和基础设施组件，这些是软件系统运行的基本部分，其中业务组件主要由业务中台、数据中台提供，基础设施一旦确定变化不大，属于技术中台的后台，技术中台主要关注集成组件、技术组件。 汽车的结构对应到软件系统就是软件的技术架构，即软件系统通过何种方式将部件组合起来运行，相同的部件可以通过不同方式的组合，产生不同的运行方式，技术架构可以分为企业集成架构和应用技术架构两种类型，前者是企业中各应用间互联互通的模式，后者是各独立应用的运行模式，不同业务特征的应用可以有不同的运行模式； 流程对应软件的全生命周期过程，同样可以分为产品设计、软件开发、软件维护几个阶段，形成几个软件工程的“流水线”； 最后，软件生产也需要很多工具，例如开发工具、监控工具、需求工具等等。 01 应用集成架构：整合企业应用能力 应用集成架构：整合企业应用能力 所谓集成就是要做整合

spring cloud本身提供的组件就很多，但我们需要按照企业的业务模式来定制企业所需要的通用架构，那我们现在需要考虑使用哪些技术呢？ 下面我针对于spring cloud微服务分布式云架构做了以下技术总结，希望可以帮助到大家： View： H5、Vue.js、Spring Tag、React、angularJs Spring Boot/Spring Cloud： Zuul、Ribbon、Feign、Turbine、Hystrix、Oauthor2、Sleuth、API Gateway、Spring Cloud、Config Eureka、SSO、Spring Cloud、 BUS、Turbine、Zipkin、Cache、Spring Cloud Admin、API Gateway、ELK Spring Cloud Security、 Spring Cloud Stream Component： RoketMQ、Kafka、MongoDB、OSS、Redis、Swagger、Zuul、Label、BASE、Charts、Utils DAO： Spring Data、Mybatis、OSS、 DTO Data Storage： RDBS DFS、NOSQL/Hadoop Infrastructure： LogBack、BUS、Jenkins、Zipkin、Druid

一、微服务架构设计中经常需要处理的问题罗列： API Gateway 内部服务间互相调用 服务发现 服务容错、熔断、降级 服务部署 数据处理 二、设计模式 1、微服务-聚合器设计模式： 聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的 WEB 页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合 DRY 原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿 X轴 和 Z轴 独立扩展。 本文作者:张永清，转载注明出处： https://www.cnblogs.com/laoqing/p/13187684.html DRY 原则： 不做重复的事（Don't Repeat Yourself），意思是说，在一个设计里，对于任何东西，都应该有且只有一个表示，其它的地方都应该引用这一处。这样需要改动的时候，只需调整这一处，所有的地方就都变更过来了。降低可管理单元复杂度的一个基本策略就是将他们拆解成更小的单元。 2、微服务-代理设计模式： 类似聚合设计模式，但是客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。 3、微服务-链式设计模式： serviceA 接收到请求后会与 serviceB

一、MPP 架构 1、MPP架构的基础概念 MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。 简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。 MPP 属于Shared Nothing，根据Shared 的不同，可以分为如下几种： Shared Everthting:一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer Shared Disk：各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac， 它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能 。 Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP