Serverless

作者 | 易立，阿里云资深技术专家，容器技术负责人 本系列文章： 第一篇 - 云原生基础设施 （已发布，文末点击阅读原文查看） 第二篇 - 云原生软件架构（本文） 第三篇 - 云原生应用交付与运维体系（待续） 前言 在《云原生基础设施》一文中我们谈到了，云原生计算包含三个维度的内容，云原生基础设施，软件架构和交付与运维体系，本文将聚焦于软件架构层面。 “Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. ” - 维基百科。 在我的理解，软件架构主要目标是解决下列挑战： 控制复杂性。 由于业务的复杂性，需要我们用更好的手段帮助研发组织克服认知障碍，更好的分工协作。分而治之，关注点分离等手段皆是如此。 应对不确定性。 业务在快速发展，需求在不断变化。即使再完美的软件架构，然而随着时间的推移，团队的变化，软件架构的调整不可避免。读《设计模式》，《微服务设计》等书字里行间写的都是“解耦”两字，让我们关注架构中确定性和不确定性的分离，提升架构的稳定性和应变能力。 管理系统性风险。 管理系统中的确定性以及不确定性风险，规避已知陷阱，对未知的风险做好准备。

作者 | 潘义文（空易） 来源|阿里巴巴云原生公众号 起源 1. 云原生（Cloud Native）的由来 云原生的概念最早开始于 2010 年， 在当时 Paul Fremantle 的一篇博客中被提及 ，他一直想用一个词表达一种架构，这种架构能描述应用程序和中间件在云环境中的良好运行状态。因此他抽象出了 Cloud Native 必须包含的属性，只有满足了这些属性才能保证良好的运行状态。当时提出云原生是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。 后来到 2013 年 Matt Stine 在推特上迅速推广云原生概念 ，并 在 2015 年《迁移到云原生架构》 一书中定义了符合云原生架构的特征： 12 因素、微服务、自服务、基于 API 协作、扛脆弱性 。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时云原生也被 12 要素变成了一个抽象的概念。Matt Stine 认为在单体架构向 Cloud Native 迁移的过程中，需要文化、组织、技术共同变革。 **解读：** 云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸 。 2. CNCF 基金会成立及云原生概念的演化 2015 年由 Linux 基金会发起了一个 The Cloud Native Computing Foundation（CNCF） 基金组织

作者 | 易立、张维 来源 | 阿里巴巴云原生公众号 导读 ：当前 Serverless 容器的行业趋势如何？有哪些应用价值？如果 Kubernetes 天生长在云上，它的架构应该如何设计？Serverless 容器需要哪些基础设施？阿里云容器服务产品负责人易立及阿里云 Serverless Kubernetes 产品 TL 张维将分享他们对 Serverless 容器架构和背后的关键思考。 从 Serverless 容器到 Serverless Kubernetes Serverless（无服务器）容器是让用户无需购买和管理服务器直接部署容器应用的产品、技术形态。 Serverless 容器可以极大提高容器应用部署的敏捷度和弹性能力，降低用户计算成本；让用户聚焦业务应用而非底层基础设施管理，极大地提高应用开发效率，降低运维成本。 目前 Kubernetes 已经成为业界容器编排系统的事实标准，基于 Kubernetes 的云原生应用生态（Helm, Istio, Knative, Kubeflow, Spark on K8s 等）更是让 Kubernetes 成为云操作系统。一方面通过 Serverless 方式根本性解决 K8s 自身的管理复杂性，让用户无需受困于 K8s 集群容量规划、安全维护、故障诊断；一方面进一步释放了云计算的能力，将安全、可用性

如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。这里我列举了目前主要的四种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。 一、单体架构 单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring mvc或者Python Drango框架的应用。其架构图如下所示： 单体架构 单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。下面是单体架构应用的一些缺点： 复杂性高 ：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战， 甚至添加一个简单的功能， 或者修改一个Bug都会带来隐含的缺陷。 技术债务 ：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积 越多。“ 不坏不修”， 这在软件开发中非常常见， 在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。 部署频率低 ：随着代码的增多

近日，阿里云MaxCompute大数据计算平台联合帆软正式发布企业级BI分析解决方案，MaxCompute成为帆软FineBI与FineReport官方数据源。此次专为企业数据分析实现的产品集成，将极大解决企业数据分析及报表应用难题，助力企业业务效率进一步提升。 MaxCompute 是阿里云提供的面向分析的企业级SaaS模式云数据仓库，服务着数以万计的客户和阿里巴巴集团。MaxCompute基于自身Serverless架构，提供快速、全托管的在线数仓服务，在消除传统数据平台的资源扩展性和弹性限制方面极具优势，同时强调面向分析的便捷性与体验，使用户经济高效的分析处理海量数据，并便捷的对接BI分析工具，真正实现从数据到洞察的高效转化。 帆软作为中国专业的大数据BI和分析平台提供商，致力于为全球企业提供一站式商业智能解决方案，旗下两款主要产品FineReport、FineBI本次与MaxCompute实现互联互通，帮助企业更好的开展以问题为导向的探索式分析工作。 目前，该联合方案已在工业和医药行业客户中得到应用和实践落地。客户基于MaxCompute构建数据仓库，对主题数据域和业务数据域的数据进行处理，各种主题数据在数仓经过分析后，向上对FineBI提供数据源查询。FineBI可通过JDBC接口连接到MaxCompute数据仓库，用户可在FineBI通过即席查询进行自助式报表处理

在线调试是云函数为了解决用户在本地搭建调试环境复杂，云上环境不便于定位等问题推出的功能。 云上的各种服务，在本地无法完全模拟，程序员大都遇到过本地和远程环境运行结果不一致的情形，追查起来费时费力，不仅效率低下，也造成非常郁闷的工作体验。 所以，能否直接在远程环境中完成全部的开发流程，是提升开发体验的最直接手段，然而在其他问题都解决后，远程调试功能是最后的一公里。 本篇文章将以一段内存泄漏的代码为例，给大家展示如何使用云函数在线调试功能定位和解决问题。Node10 及以上版本的 runtime，使用 Chrome 浏览器打开云函数控制台，在函数代码页即可看到在线调试的入口。 开启调试模式 使用Chrome浏览器打开函数代码编辑页，可以看到在【远程调试】页。为保障调试的体验，开启调试模式将修改函数的部分配置，包括函数进入单实例模式、函数超时时间修改为900秒等。开启前请务必确认这些调整。 待加载完成后，页面将自动展示入口文件。 找不到需要的文件？ 使用快捷键 Cmd + P（Mac）或 Ctrl + P（Windows）可以打开所需要的文件。但大家可能会发现，刚开启调试模式时，打开文件的列表中找不到所需要的文件。 这是因为对于动态脚本语言来说，调试器不会加载所有的内容，只会加载执行过的文件。我们先点击测试，让函数运行一次。在运行一次后，我们就可以打开所需要的文件了。 设置断点