API-Gateway

“Serverless 能取代微服务吗？” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。也有人说，因为 Serverless 内含的 Function 可以视为更小的、原子化的服务，天然地契合微服务的一些理念，所以 Serverless 与微服务是天作之合。马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。 从概念上讲，微服务完全符合 Serverless 功能结构，微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面，像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库，并独立地进行扩展。 在我们深入探讨细节之前，先别急着“站队”，不妨先基于你团队的实际情况，真实的去思考是否适合使用微服务，千万不要因为 "这是趋势 "而去选择它。 微服务在 Serverless 环境下的优势 可选择的可扩展性和并发性 Serverless 让管理并发性和可扩展性变得容易。在微服务架构中，我们最大限度地利用了这一点。每一个微服务都可以根据自己的需求对并发性/可扩展性进行设置

简介： 马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。 来源 | Serverless 公众号 编译 | OrangeJ 作者 | Mariliis Retter “Serverless 能取代微服务吗？” 这是知乎上 Serverless 分类的高热话题。 有人说微服务与 Serverless 是相背离的，虽然我们可以基于 Serverless 后端来构建微服务，但在微服务和 Serverless 之间并不存在直接的路径。也有人说，因为 Serverless 内含的 Function 可以视为更小的、原子化的服务，天然地契合微服务的一些理念，所以 Serverless 与微服务是天作之合。马上就要 2021 年了，Serverless 是否终将取代微服务？从微服务到 Serverless 需要经过怎样的路径？本文将对 Serverless 与微服务在优势劣势上进行深度对比。 从概念上讲，微服务完全符合 Serverless 功能结构，微服务可以轻松实现不同服务的部署和运行时隔离。在存储方面，像 DynamoDB 这样的服务可以让每个微服务拥有独立的数据库，并独立地进行扩展。 在我们深入探讨细节之前，先别急着“站队”

这是“领域驱动设计实践之路”系列的第四篇文章，从单体架构的弊端引入微服务，结合领域驱动的概念介绍了如何做微服务划分、设计领域模型并展示了整体的微服务化的系统架构设计。结合分层架构、六边形架构和整洁架构的思想，以实际使用场景为背景，展示了一个微服务的程序结构设计。 一、单体架构的弊端 单体结构示例(引用自互联网) 一般在业务发展的初期，整个应用涉及的功能需求较少，相对比较简单，单体架构的应用比较容易部署、测试，横向扩展也比较易实现。 然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。 下面分析下单体架构应用存在的一些弊端： 1、复杂性高 在项目初期应该有人可以做到对应用各个功能和实现了如指掌，随着业务需求的增多，各种业务流程错综复杂的揉在一起，整个系统变得庞大且复杂，以至于很少有开发者清楚每一个功能和业务流程细节。 这样会使得新业务的需求评估或者异常问题定位会占用较多的时间，同时也蕴含着未知风险。更糟糕的是，这种极度的复杂性会形成一种恶性循环，每一次更改都会使得系统变得更复杂，更难懂。 2.技术债务多 随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。比如，团队必须长期使用一套相同的技术栈，很难采用新的框架和编程语言。有时候想引入一些新的工具时

作者 | 宋文龙（闻可） 阿里云全球技术服务部高级交付专家 来源 | Serverless 公众号 什么是无服务计算 无服务器计算（Serverless Computing）在构建和运行应用时无需管理服务器等基础设施。它描述了一个细粒度的部署模型，在该模型中，应用被拆解为一个或多个细颗粒度的函数，在云端托管环境中被触发运行，然后根据需要执行、扩展容量并且计费。各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出 Serverless 产品。 无服务计算本身是一个概念或者理论模型，落地到具体技术上主要有函数即服务（FaaS）以及后端即服务（BaaS）两种形式，阿里云提供函数即服务 FaaS 产品。 阿里云对于 FaaS 的定义如下： 函数计算是事件驱动的全托管计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算为您准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。 关于 FaaS 的详细介绍 官方文档 已经讲的很清楚，本文不再赘述。本文重点讨论无服务计算的应用场景以及应用实践。 无服务计算应用场景 1. 无服务计算的优势 无服务计算有很多优点，个人认为其中最主要的有三点： 使用无服务计算，用户无需考虑基础设施，可以更加专注于业务逻辑； 无服务计算支持弹性伸缩，按需使用，按量计费

客户端直接访问微服务带来的问题 1、客户端的需求量与每个微服务暴露的细粒度API数量的不匹配。 2、亚马逊的产品最终页要请求数百个微服务。虽然一个客户端可以通过LAN发起很多个请求，但是在公网上这样会很没有效率，这个问题在移动互联网上尤为突出。这个方案同时会导致客户端代码非常复杂。 3、另一个存在的问题是客户端直接请求微服务的协议可能并不是web友好型。一个服务可能是用Thrift的RPC协议，而另一个服务可能是用AMQP消息协议。它们都不是浏览或防火墙友好的，并且最好是内部使用。应用应该在防火墙外采用类似HTTP或者WEBSocket协议。 4、另一个缺点是它很难重构微服务。随着时间的推移，我们可能需要改变系统微服务目前的切分方案。例如，我们可能需要将两个服务合并或者将一个服务拆分为多个。但是，如果客户端直接与微服务交互，那么这种重构就很难实施。 由于上述问题的原因，客户端直接与服务器端通信的方式很少在实际中使用。 使用API Gateway API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facet模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。 API Gateway负责请求转发、合成和协议转换

导读 作为国民级出行生活服务平台，高德服务的稳定性不论是平时还是节假日都是至关重要的，服务稳定性一旦出问题，可能影响千万级甚至上亿用户。春节、十一等节假日激增的用户使用量，给高德整体服务的稳定性带来了不小的挑战。每年在大型节假日前我们都会做整体服务的全链路压测。通过常态化全链路压测项目的推进，已具备了月度级别的常态化全链路压测能力，把战前演练提到日常，持续推进稳定性保障建设。 TestPG压测平台2018年9月启动，在2019年春节第一次支撑高德全链路压测任务，当时前后花了近2周的时间才完成3个机房的压测任务。后来成立了常态化全链路压测项目，通过对流程的优化以及压测平台技术能力的升级，现在已经具备了1天内完成全国3个机房全链路压测的能力。大型节假日的全链路压测周期缩短到了3天。 全链路压测的常态化不仅对高德整体服务的稳定性建设起到了推动作用，而且也推动了流程上的优化以及压测平台在技术能力上的改进提升。具体而言，我们主要从压测前的语料准备和压测过程中的压力调控两个方面入手，通过语料平台化生产，规范语料生成流程，对语料生产提效；通过压测过程中对发压能力的精准调控，使我们能够灵活调整压力模型，从而使其更加接近于线上真实情况，让全链路压测过程平滑流畅，效率提升。本文会重点介绍TestPG压测平台在发压能力精准调控方面的建设实践。 压力调控的两个主要问题

ORY Oathkeeper is an Identity & Access Proxy (IAP) that authorizes HTTP requests based on sets of rules. The BeyondCorp Model is designed by Google and secures applications in Zero-Trust networks. An Identity & Access Proxy is typically deployed in front of (think API Gateway) web-facing applications and is capable of authenticating and optionally authorizing access requests. While the full feature set of the BeyondCorp Whitepaper is not yet implemented, the goal of this project is to achieve this in the future. ORY Oathkeeper is a reverse proxy which evaluates incoming HTTP requests based on