兔子酱
TA的个人档案
个人介绍
暂无个人介绍
擅长的技术
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2018-10-12
专访蚂蚁金服mPaaS｜移动下半场，不仅仅是技术能力开放
小蚂蚁说： mPaaS 是 mobile Platform-as-a-Service的简称。如果你熟悉云计算的话，对PaaS这个概念一定不会陌生，而mPaaS这个概念则由蚂蚁金服独创，沉淀于蚂蚁金服多年移动端技术实践和高并发业务体量锤炼。 mPaaS除却传统金融案例外，更在深度赋能12306、上海地铁等在内的民生项目完成架构升级，真正将移动技术应用到业务场景中，实现“微小而美好的改变”。 本文是对mPaaS产品负责人、蚂蚁金服高级产品专家张亮（花名：方略）的采访，他全面介绍了mPaaS的故事，一起来看看吧！ 相关阅读：《如何迅速开发一款移动App？蚂蚁金服移动开发平台mPaaS已帮你写好了答案》 mPaaS的产品负责人在2018ATEC大会中的现场直播 Q1：您好，可否先介绍一下蚂蚁金服移动开发平台mPaaS？ 张亮：好的，我叫张亮，我是蚂蚁金服移动开发平台mPaaS的产品负责人。mPaaS，即mobile PaaS，简单来说它是源于支付宝技术的一个移动开发平台，包含了移动开发、测试、发布、分析、运营各个方面的云到端的一体化的解决方案，展开来讲可以分为三个产品维度： 第一个维度 「客户端能力」，丰富的前端模块加速开发，处处动态，千人千面。 主要是基于加速移动App开发，让开发者高效开发 App所需的相关技术： 这一层是通常所理解的移动开发能力，主要包含了三部分：开发框架、UI库、还有工具类的SDK。 开发框架 1、Native开发框架，也就是原生的iOS和安卓开发框架；其拆包理念适合大团队协同开发，可以有效的提高开发效率和 App的整体架构合理性 2、H5开发框架，支持混合开发的模式。与mPaaS离线包，发布服务，UCWebView完美结合提供极高的灵活性和性能体验 3、支付宝小程序开发框架。面向未来的开发框架，可以围绕自己的 App ，开放业务接口，构架开发生态。 UI 库 mPaaS 统一组件库（AntUI）以标准化的视觉规范为基础，将抽象的视觉规范概念转化为控件实体。作为开发人员，通过使用统一组件库，可以在接入控件时，实现客户端视觉规范的统一。AntUI 支持Native 和 H5。AntUI 目前支持 41 种空间类型，128个控件 客户端 SDK mPaaS 还提供了丰富的客户端 SDK，例如扫码，本地缓存，客户端埋点等20多个组件，可以让开发者快速接入搭建 App 所需要的基础能力，专注业务逻辑的开发。 第二个维度 「移动中台」，坚实的中台运行期管控，支持端上业务的快速变更，创新。 除了客户端开发之外，还提供了移动中台中台能力，来对App的整个生命周期进行管理，包括App研发、测试、发布、分析、运营在内的各个环节。 - 研发阶段： 提供的“研发协同平台”能够和底层的开发框架相结合，让开发者进行协同研发、持续集成，持续发布，最终让代码转换成能够安装到手机本地的包； - 测试阶段： 熟悉安卓市场的人都知道，在中国，安卓市场碎片化比较严重，需要确保App能够运行在大部分的安卓机型上面，避免上线后发生严重的闪退等问题。这就意味着我们必须要在上线之前对App进行全面，统一的测试，来验证 App的兼容性、功能性以及稳定性，如果没有问题我们才可以进入到下一阶段。“真机云测”提供了包括测试框架，真机管理，测试用例管理，测试结果报告等能力 - 发布阶段： 测试完成一般就可以进入发布阶段了，支付宝在经过多年的实践之后也总结了一套发布的方法论，并融合了到 mPaaS “移动发布服务”中： 首先是白名单发布：当开发完毕后，开发者可以在“移动发布服务”中配置发布白名单，优先在自己的手机上完成发布测试； 其次是内部灰度测试：在这个阶段，可以把白名单扩大到更大的范围，对内部员工或者其他比较安全的群体进行发布； 再接着是外部灰度测试：这可阶段就可以对外了，但只针对一小部分用户，“移动发布服务”可以根据用户，设备属性属性对用户进行分组，比如可以定向给在某个省市的华为的某个机型进行外部灰度发布，并进行实时发布监控，发现问题 最后，如果外部灰度测试没有问题，一般来说就可以判断新版App已是趋于稳定的版本，那就可以把进行全网发布了。 - 分析阶段： 完成发布工作后，App已经运行在了客户的手机上，接下来我们还需要对App的日常运行进行实时监控和分析，包括用户行为轨迹追踪和App性能分析： • 用户行为分析：包含了实时大盘，用户行为，留存分析，设备分析，页面分析等 • 性能分析：包含了，闪退分析，卡顿包括，卡死报告等 • 自定义分析：自定义事件分析，自定义漏斗分析，自定义大盘 • 日志管理：按照用户或设备ID纬度对原始日志进行查询 以“上海地铁”举例，基于mPaaS平台，“上海地铁”有能力针对每一条线路上每一个用户从扫码到进站具体花多少时长完成实时统计分析，从而优化后期的资源调度。 - 运营阶段： 随着面向业务场景的分析能力深度应用，一方面运营方能够提前预测潜在业务风险，另一方面即使有业务需求，也具备针对性运营的能力。mPaaS 提供了： • 智能投放：对App 内的营销内容进行统一管理，包括了展位管理，素材管理，活动管理（人群定向，展示频率等），活动分析等能力 • 消息推送：绿色消息推送能力，接入了小米，华为等系统推送能力，高达到率，低资源消耗 • 舆情分析：对 App 内反馈，外部媒体报告进行统一管理，即时发现舆论方向，并可以进行报警 移动中台是 mPaaS的一个重要的特色，在研发测试期提供给了工具和支付宝的最佳事件经验，提高开发效率，强化流程管理。在运行期，提供了灵活的管控能力，可以动态控制 App 的行为。在分析，运营期，提供了多种工具，全面了解 App 的运行状况，并有针对性的进行运营。 第三个维度 「后台连接」，延展上层业务能力。 客户端开发和移动中台能力都是针对 App 本身，但一个完整的 App仍需要通过服务端来获取更高阶的能力，比如转账，单纯靠App自身无法完成数据同步，需要调用到服务端数据。在支付宝的场景里，我们通过 API 调用统一的网关服务来实现。 其次，我们也开放了大数据通道（多媒体通道），能够支持App间文件断点续传，分片下载等，可以有效的提供下载速度和成功率。 因此，mPaaS 主要包含了客户端开发、移动中台管控、后台连接服务三层能力。 Q2：谢谢对mPaaS详细的介绍，我们也非常好奇这个产品在蚂蚁金服内部孵化的背景是什么？为何mPaaS的诞生是一件必须的事情？ 这是一个很有意思的问题。 从行业趋势看，蚂蚁金服在过去几年高速发展，因此普惠金融、互联网金融的概念已经深入民心，越来越多传统金融公司开始重点发展互联网金融服务，因此整个行业的技术创新氛围是非常活跃的； 从蚂蚁自身业务看，蚂蚁金服在继支付宝之后还推出了网商银行、口碑App，同时扩展了包括支付宝香港版、印度Paytm、印尼 Dana等在内的海外业务，需要快速对新的业务进行技术赋能，而这恰好也成为了技术持续迭代的驱动力。 其次是蚂蚁金服移动开发技术的能力的成熟： 在过去几年，经过双11、双12高并发业务的检验，目前支付宝在复杂的业务场景中支持了亿级日活用户，同时结合日益丰富的业务场景锤炼，我们已具备了对外输出技术能力的条件。 最后结合蚂蚁金服“为世界带来微小而美好的改变”的愿景： 在2015年9月份支付宝便提出“互联网推进器”计划，开放蚂蚁的成熟技术来服务更多的金融机构，帮助他们完成业务升级，普惠金融，与全行业一起做大市场，给中国的老百姓带来实实在在的优惠。 所有，技术条件成熟，市场需求旺盛，公司发展战略的驱动，这一切都促进了这个产品的落地。 Q3：通过蚂蚁金服的技术和经验积累能够帮助开发者释放很多生产力，因此可否聊聊mPaaS这款产品在定位和理念设计上有哪些独到的思考？ 这是一个很好的问题，我认为一个优秀的产品肯定离不开先进的理念来支撑，否则这个产品就是一个没有灵魂的产品。 比如mPaaS第一个维度的开发框架，我们便植入了很多先进的产品理念，比如拆包能力。 什么叫拆包能力？在蚂蚁金服内部，一款App开发的过程会拆成业务独立的不同bundle，或子App,然后由各个团队独立进行开发，由框架管理子App之间的依赖和生命周期，并最终合并成一个面向用户的 App，这样可以有效的提供研发效率，降低新功能上线的周期。 还有低耦合性，mPaaS 所有的能力和框架都可以单独接入，并不强制要求用户全部使用。所有的能力和框架都可以单独接入，但如果能互相配合，显然会有更好的便利性： 移动中台的定位和概念，也是业界相对先进的一个产品理念：通过中台确保App在运行期的稳定性和动态化更新。 比如在双11双12大促前，当我要确保支付通道的足够稳定时，用户具体访问、点击行为的追踪分析显得没有那么重要，那么我可以通过中台下发指令让所有客户端无需再上报用户行为日志，由此能够确保主链路的高可用和稳定性。不仅是日志行为可以得到控制，包括离线包、热修复、动态开关等能力，通过mPaaS移动过中台得到动态调控，给后期业务运营提供非常大的灵活性和便利性。 前后端分离，mPaaS通过统一的网关服务来管理所有访问请求，因此前后端在网关定义的接口可以单独调用、配置、更新，从而确保前后端的开发完全分离。同时，在双11大促期间，通过网关层可以进行集中式管控，当后台系统达到峰值极限时，能够有效限制拒绝其他访问，避免系统崩溃。目前，网关能力在支付宝网络环境里可保持99.999% 的可用率。 Q4：在开发mPaaS这款产品期间有无遇到什么困难和挑战，又是如何解决的呢？ 跟传统 IT 企业不同，蚂蚁金服的产品都是先经过内部业务验证过，再对外输出。这是我们的优势，当然这种新的模式也带来了一些挑战： • 内部产品比较多，我们应该以什么样的顺序对外输出，这是我们当初面临的一个比较实际的问题。 mPaaS 1.0 首先回到用户的需求，我们针对App Store上的金融类应用开展了深入的市场调研，了解这些应用的实际用户反馈了哪些需求，在实际体验中遇到了哪些问题。最终，调研结果指向了“稳定性能”和“流畅体验”两个要素。 显然，目前具备App开发能力已不是问题，但如何开发一款高质量的App才是核心痛点。因此，mPaaS 1.0首先开放支付宝的底层开发框架、UI库、网关服务以及移动分析能力，只有具备实时监控分析产品性能的能力，才能持续针对性地提升App性能。 mPaaS 2.0 随着mPaaS有越来越多的客户接入，他们对业务创新、对开发效率提出了更高要求： 于是mPaaS 2.0逐步开放发布平台、热修复、离线包、数据同步等能力，更深入地改变了传统金融机构的研发模式。 mPaaS 3.0 接下来我们再更进一步地贴近业务，从一个技术开放平台往业务中台进行过渡，接下来我们会推出营销管理，舆情分析等能力，这是mPaaS 3.0的核心理念。 • 还有一个问题是mPaaS如何做到能力的通用性，一方面我们要做到研发能力的通用性，能够应对不同业务类型和场景；另一方面如何能够深入业务场景传递蚂蚁的经验和想法。mPaaS 不断梳理自有的产品逻辑，并将产品高度地抽象化，做到普适性，同时能够在核心的产品能力矩阵和使用流程中保留蚂蚁先进的经验和技术，从而达到比较好的平衡状态。 举个例子，mPaaS 智能投放平台，我们优先抽取了产品的核心能力，即根据用户性别、地域、机型等标签，进行定向投放；同时我们在基础能力之上构建插件化扩展能力，比如投放的人群定向分类管理、投放和展示频次等，可以根据mPaaS AI 平台做更深度智能的决策。 先释放核心的能力，让客户能够基于核心能力深度应用，此后延伸出来更细化的需求，我们可以通过插件的形式不断丰富和完善功能，这也是我们平衡产品需求和开发资源的一个做法。 Q5：显然一款技术产品需要结合行业特征，深入业务场景才能最大化技术价值，可否结合上海地铁、12306等案例，展开聊聊mPaaS如何做到技术赋能，同时又影响我们普通人的生活？ mPaaS正式推广是在2017年下半年，主要围绕公司战略，一方面助理金融行业的升级转型，目前主要面向的是股份制银行，和城商行，例如广发银行，华夏银行，苏州银行，西安银行，常熟银行，助力金融机构做互联网金融升级，一般以直销银行，手机银行体验升级，智慧银行，移动开发平台建设等项目居多，大家感兴趣的话可以关注我们蚂蚁金服科技公众号，了解一些有代表性的项目。 另外一方面蚂蚁金服一直致力于为人们生活带来微小而美好的改变，这方面主要是跟蚂蚁开放平台客户一起服务生态，比如上海地铁，12306等： 目前上海地铁日均轨道交通客流已超过1100万人次，在一些重要的站点比如虹桥火车站，流量疏通的压力依旧非常大。因此，2017年上海地铁策划了手机扫码进展的功能，并与蚂蚁金服，mPaaS团队进行了深入的合作，推出了“Metro大都会 App”，和核心扫码进站能力。项目中，mPaaS 除了输出了开发框架，网关，离线包，热修复等能力，还是一次大规模的业务能力输出的尝试，通过了 AlipayInside 输出了码能力，支付能力等，可以很方便的以SDK的方式集成到 App 中。“Metro 大都会 App”的扫码进展能力，切实的解决了排队买票的问题，提供了地铁运营的效率。 除了城市轨道交通，每年的春运同样给铁路运输容载能力提出巨大挑战。据悉，2018年春运售票线上渠道占比77.7%，其中移动端购买占比 55.3%，且售票体量已达到日均千万级。12306团队在2017年希望能够针对原有的App完成一次大规模升级，以应对高并发、大体量的业务挑战。mPaaS团队在2017年8月介入项目，在不到三个月的时间，帮助12306 App 完成重构，且在2018年春运期间没有发现任何影响用户购票体验的重大问题；同时借助mPaaS众多产品组件，12306 App后续开发效率，性能和体验都有了显著的提升。 未来，mPaaS团队会继续深耕更多行业，帮助更多行业创造“微小而美好的改变”，从而提高大家的生活质量，请大家拭目以待。 结语 结合蚂蚁金服“为世界带来微小而美好的改变”的愿景，mPaaS不仅仅只释放移动技术能力，更希望能够和行业一起，深入垂直场景，思考背后的业务痛点和产品逻辑，充分把技术沉淀和产品力结合起来，这不是简单的重复造轮子，而是希望真正地做到技术驱动业务创新、业务带来美好体验。 — END — 蚂蚁金服官方唯一对外技术传播渠道 投稿邮箱：anttechpr@service.alipay.com 欢迎留言及个人转发，媒体转载请联系授权
-
发表了文章 2018-10-11
OSDI '18重磅解密：蚂蚁金服实时金融级分布式图数据库GeaBase
小蚂蚁说： GeaBase是具备高性能、高可用、高扩展性及可移植性强的实时金融级分布式图数据库，广泛应用于蚂蚁金服风控、社交、推荐等技术场景。“过无人区” 、“Made in China” 、“反哺”是GeaBase的几个耀眼标签。每年的支付宝春节红包、每一笔交易的反洗钱识别等等，背后的技术都少不了它的身影。 背景阅读：以往文章《GeaBase，中国首个金融级分布式图数据库诞生记》 当地时间2018年10月8日-10日，全球极富盛名的计算机学界顶级学术会议OSDI '18（USENIX Symposium on Operating Systems Design and Implementation，简称OSDI）在美国加州卡尔斯巴德举办。 OSDI大会期间，在蚂蚁金服主办的专题研讨会上，其中主题为《GeaBase: A High-Performance Distributed Graph Database for Industry-Scale Applications》的演讲吸引了多位来自全球的顶尖技术专家和学者，并引发了现场热烈的讨论。 蚂蚁金服集团计算存储首席架构师何昌华 图数据库“明星”——蚂蚁金服GeaBase 众所周知，近十年来，图数据库一直是业界关注的焦点，未来的前景也被普遍看好，其最大优点是通过节点和关联的数据模型去快速解决复杂的关系问题。毫不夸张地说，图数据库是为当前丰富、快速变化的互联网应用场景而生的，因为它非常善于处理大量的、复杂的、关联的、多变的网状数据，而且具备奇高的效率。 由于图数据库拥有独一无二的特性，因此它非常适合在社交网络、实时推荐、银行交易环路、金融征信系统等领域应用。基于此，蚂蚁金服前瞻性地在2015年成立了专门研发图数据库的技术团队，在仅仅3年多时间里，成功研发出具有高性能、高可用性、扩展能力强和极佳移植性的GeaBase。 蚂蚁金服平台数据技术事业群高级算法专家付志嵩 据蚂蚁金服集团相关技术专家介绍，GeaBase（Graph Exploration and Analytics Database）是蚂蚁金服完全自主研发的实时金融级分布式图数据库，目前，GeaBase不仅广泛应用于蚂蚁金服的生态体系内，而且已经商业化和技术对外开发，正与多家银行等企业开展合作。 蚂蚁金服平台数据技术事业群高级技术专家肖涵 GeaBase到底强在哪里？ 据介绍，蚂蚁金服研发GeaBase的初衷是为了满足超大规模复杂关系网络在金融领域中的各类应用场景，既要支撑线上高并发、低延迟的实时查询需求，又要满足大规模模型训练的迭代运算。 GeaBase的技术架构 一起看看GeaBase的基本特性。 首先，GeaBase支持海量的数据。目前，GeaBase支撑着蚂蚁金服的多个关键应用场景，包括风控关系网络、资金关系网络，都达到百亿个节点、千亿条边的海量数据规模，其计算查询能力达到了非常高的水准。 其次，GeaBase拥有非常强悍的在线查询性能，支持高并发，且具备毫秒级的低延时能力。通过与Titan的对比，可以看到无论是延时还是吞吐量，GeaBase的查询性能都领先许多。 GeaBase还具备高可用的特性。其配置了多种容错机制，引入了多集群和多方位的监控体系，并配备了分布式架构的容灾方案，这一切都是为了保证高可用性。 蚂蚁金服还为GeaBase研发了灵活且可扩展的查询语言。另外，为了和开源结合，GeaBase还将支持Gremlin图遍历语言。 GeaBase的雄心：商业化和技术开发 据了解，GeaBase现在支撑着蚂蚁金服旗下支付的风险控制、反洗钱、反欺诈、反刷单、反套现、金融案件审理、知识图谱、会员拉新、好友推荐、理财资讯推荐等众多的业务和应用。 尽管已经在蚂蚁金服的生态的多个业务场景得到广泛应用，但GeaBase的雄心显然不止于此，它是蚂蚁金服整体的金融科技开放战略的坚定执行者。 目前，业界很多互联网公司都在做图数据库方面的研究工作，但其中绝大多数都是基于自身系统的，因此具有较强的依赖性，剥离起来比较麻烦。而现在市面上已经商业化的图数据库又几乎都不是分布式的系统，其目标用户也主要是数据量较小的中小型企业。 蚂蚁金服在设计之初就充分考虑了GeaBase系统移植的问题，因此，将其封装成产品，打造为高效易用的接入和管控产品化平台。这样的好处显而易见，那就是GeaBase可以轻松地移植到外部客户的系统之中，也正因为如此，GeaBase受到银行等企业的热烈追捧。据介绍，目前已经有十余家银行有意向配置GeaBase，而且部分企业已经与蚂蚁金服签订合作协议。 关于GeaBase的更多内容，请浏览蚂蚁金融科技官网： https://tech.antfin.com/ — END — 蚂蚁金服官方唯一对外技术传播渠道 投稿邮箱：anttechpr@service.alipay.com 欢迎留言及个人转发，媒体转载请联系授权
-
发表了文章 2018-10-10
SOFAMesh解决方案x-protocol介绍系列(1) ： DNS通用寻址方案
小蚂蚁说： 2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，并在6月底正式对外公布了 SOFAMesh，详情可直接点击之前的文章查看: 大规模微服务架构下的Service Mesh探索之路 。 在 SOFAMesh 的开发过程中，针对遇到的实际问题，我们给出了一套名为 x-protocol 的解决方案，本文将会对这个解决方案进行详细的讲解，后面会有更多内容，欢迎持续关注本系列文章。 前言 x-protocol 的定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。 具体解决的问题包括： 多通讯协议支持问题，减少开发工作量，简单快捷的接入新协议 尽量提升性能，提供更灵活的性能与功能的平衡点选择，满足特定高性能场景 兼容现有SOA体系，提供通过接口进行访问的方式，实现不修改业务代码也能顺利接入 Service Mesh 支持单进程多服务的传统SOA程序，可以在微服务改造之前，先受益于 Service Mesh 带来的强大功能 在本系列文章中，我们将对此进行详细的讲解，首先是“DNS通用寻址方案”。 背景和需求 SOA的服务模型 在SOFAMesh计划支持的RPC框架中，SOFARPC、HSF、Dubbo都是一脉相承的SOA体系，也都支持经典的SOA服务模型，通常称为”单进程多服务”，或者叫做”单进程多接口”。（备注：由于服务一词使用过于频繁，下文都统一称为接口以便区分） SOA标准的服务注册，服务发现和调用流程如下： 在单个SOA应用进程内，存在多个接口 服务注册时，以接口为单位进行多次独立的服务注册 当客户端进行调用时，按照接口进行服务发现，然后发起调用 当我们试图将这些SOA架构的应用搬迁到ServiceMesh时，就会遇到服务模型的问题：微服务是单服务模型，也就是一个进程里面只承载一个服务。以k8s的服务注册为例，在单进程单服务的模型下，服务名和应用名可以视为一体，k8s的自动服务注册会将应用名作为服务注册的标示。 这就直接导致了SOA模型和微服务模型的不匹配问题： SOA以接口为单位做服务注册和服务发现，而微服务下是服务名 SOA是”单进程多接口”，而微服务是”单进程单服务” 一步接一步的需求 先上车后补票 最理想的做法当然是先进行微服务改造，实现微服务拆分。但是考虑到现有应用数量众多，我们可能更愿意在大规模微服务改造之前，先想办法让这些应用可以运行在ServiceMesh下，提前受益于ServiceMesh带来的强大功能。因此，我们需要找到一个合适的方案，让ServiceMesh支持没有做微服务改造依然是”单进程多接口”形式的传统SOA应用，所谓”先上车后补票”。 不修改代码 考虑到原有的SOA应用，相互之间错综复杂的调用关系，最好不要修改代码，即保持客户端依然通过接口名来访问的方式。当然，SOA架构的客户端SDK可能要进行改动，将原有的通过接口名进行服务发现再自行负载均衡进行远程调用的方式，精简为标准的ServiceMesh调用（即走Sidecar），因此修改SDK依赖包和重新打包应用是不可避免。 支持带特殊字符的接口名 k8s的服务注册，Service名是不能携带”.“号的。而SOA架构下，接口名有时出于管理方便，有可能是加了域名前缀，如”com.alipay.demo.interface-2”。为了实现不修改原有代码，就只能想办法支持这种带特殊字符的接口名。 参考Kubernetes和Istio 在进一步讨论解决方案之前，我们先来看一下kubernetes和istio中的标准请求寻址方式。 （备注：过程稍显复杂，涉及到k8s/istio的一些底层细节。但是了解这个过程对后续的理解非常重要，也可以帮助大家了解k8s和k8s的工作原理，强烈推荐阅读。） k8s下的DNS寻址方式 在k8s下，如图所示，假定我们部署了一个名为userservice的应用，有三个实例，分别在三个pod中。则应用部署之后，k8s会为这个应用分配ClusterIP和域名，并在DNS中生成一条DNS记录，将域名映射到ClusterIP： 当部署在k8s下的某个充当客户端的应用发起请求时，如图中的HTTP GET请求，目标URL地址为 “http://userservice/id/1000221"。请求的寻址方式和过程如下： 首先进行域名解析，分别尝试解析”userservice”/“userservie.default.svc.cluster.local”等域名，得到ClusterIP 然后客户端发出请求的报文，目标地址为ClusterIP，源地址为当前客户端所在的pod IP（简单起见，端口先忽略） 请求报文随即被kube-proxy拦截，kube-proxy根据ClusterIP，拿到ClusterIP对应的多个实际服务实例所在的pod ip，取其中一个，修改目标地址为这个pod IP 请求报文最终就被发送到服务实例所在的pod IP 应答回来的方式类似，userservice发出的应答报文会被kube-proxy拦截并修改为发送到客户端所在的pod IP。 我们详细看一下请求和应答全称的四个请求包的具体内容（简单起见继续忽略端口）： 重点关注请求和应答报文的源地址和目标地址： 客户端发出的请求，为”客户端到ClusterIP” kube-proxy拦截到请求后，将请求修改为”客户端到服务器端” 服务器端收到请求时，表现为”客户端到服务器端”，ClusterIP被kube-proxy屏蔽 服务器端发送应答，因为收到的请求看似来自客户端，因此应答报文为”服务器端到客户端” 应答报文被kube-proxy拦截，将应答修改为”ClusterIP到服务器端” 客户端收到应答，表现为”ClusterIP到服务器端”，服务器端IP被kube-proxy屏蔽 kube-proxy在客户端和服务器端之间拦截并修改请求和应答的报文，联通两者，但各自屏蔽了一些信息： 在客户端看来它是在和ClusterIP交互，userservice的具体服务器端实例对客户端是无感知的 在服务器端看来，客户端是直接在和它交互，ClusterIP的存在对服务器端是无感知的 更深入一步，看kube-proxy在两个拦截和修改报文中的逻辑处理关系，即kube-proxy是如何在收到应答时正确的找回原有的ClusterIP： 在拦截并修改请求报文之后，kube-proxy会保存报文修改的5元组对应关系（5元组指源IP地址，源端口，协议，目的地IP地址，目的地端口） 在收到应答报文后，根据应答报文中的5元组，在保存的5元组对应关系中，找到对应信息，得到原有的ClusterIP和端口，然后修改应答报文 总结，通过上述k8s下的寻址方式，客户端只需发送带简单寻址信息的请求（如 “http://userservice/id/1000221" 中的”userservice” ），就可以寻址到正确的服务器端。这期间有两个关注点： 通过DNS，建立了域名和ClusterIP的关系。 对于客户端，这是它能看到的内容，非常的简单，域名、DNS是非常容易使用的。 而通过kube-proxy的拦截和转发，又打通了ClusterIP和服务器端实际的Pod IP 对于客户端，这些是看不到的内容，不管有多复杂，都是k8s在底层完成，对客户端，或者说使用者透明。 以客户端的视角看来，这个DNS寻址方式非常的简单直白： Istio的DNS寻址方式 Istio的请求寻址方式和普通kubernetes非常相似，原理相同，只是kube-proxy被sidecar取代，然后sidecar的部署方式是在pod内部署，而且客户端和服务器端各有一个sidecar。其他基本一致，除了图中红色文本的部分： iptables在劫持流量时，除了将请求转发到localhost的Sidecar处外，还额外的在请求报文的TCP options 中将 ClusterIP 保存为 original dest。 在 Sidecar （Istio默认是Envoy）中，从请求报文 TCP options 的 original dest 处获取 ClusterIP 通过TCP options 的 original dest，iptables就实现了在劫持流量到Sidecar的过程中，额外传递了 ClusterIP 这个重要参数。Istio为什么要如此费力的传递这个 ClusterIP 呢？ 看下图就知道了，这是一个 Virtual Host 的示例， Istio 通过 Pilot 将这个规则发送给 Sidecar/Envoy ，依靠这个信息来匹配路由请求找到处理请求的cluster： domains中，除了列出域名外，还有一个特殊的IP地址，这个就是k8s服务的 ClusterIP！因此，Sidecar可以通过前面传递过来的 ClusterIP 在这里进行路由匹配（当然也可以从报文中获取destination然后通过域名匹配）。 总结，Istio延续了k8s的寻址方式，客户端同样只需发送带简单寻址信息的请求，就可以寻址到正确的服务器端。这期间同样有两个关注点： 通过DNS，建立了域名和ClusterIP的关系。 通过 ClusterIP 和 Pilot 下发给 Virtual Host 的配置，Sidecar 可以完成路由匹配，将ClusterIP和目标服务器关联起来 同样，对于客户端，这些是看不到的内容。 因此，以客户端的视角看来，Isito的这个DNS寻址方式同样的简单直白！ DNS通用寻址方案具体介绍 解决问题的思路 在详细讲述了k8s和istio的DNS寻址方案之后，我们继续回到我们的主题，我们要解决的问题： 如何在不修改代码，继续使用接口的情况下，实现在Service Mesh上运行现有的Dubbo/HSF/SOFA等传统SOA应用？ 这里有一个关键点：k8s的服务注册是以基于Service或者说基于应用(app name)，而我们的客户端代码是基于接口的。因此，在 Virtual Host 进行路由匹配时，是不能通过域名匹配的。当然，这里理论上还有一个思路，就是将接口注册为k8s Service。但是，还记得要支持接口特殊字符的需求吗？带点号的接口名，k8s是不能接受它作为Service Name的，直接堵死了将接口名注册到k8s Service的道路。 这样，我们就只有一条路可以走了：效仿istio的做法，通过 ClusterIP 匹配！ 而要将接口名（如”com.alipay.demo.interface-1”）和 ClusterIP 关联，最简单直接的方式就是打通DNS ： 只需要在DNS记录中，增加接口到 ClusterIP 的映射，然后就可以完全延续Istio的标准做法！其他的步骤，如域名解析到ClusterIP，iptables拦截并传递ClusterIP，sidecar读取ClusterIP并匹配路由，都完全可以重用原有方案。 具体实现方案 实现时，我们选择了使用 CoreDNS 作为k8s的DNS解决方案，然后通过 Service Controller 操作 CoreDNS 的记录来实现DNS解析。 为了收集到SOA应用的接口信息，我们还提供了一个 Register Agent 给 Service Controller 收集信息。 详细的实现方案，不在本文中重复讲述，请参阅我们之前的分享文章 SOFAMesh 的通用协议扩展 中的DNS寻址方案一节。 （备注：暂时修改 CoreDNS 记录的方式是直接修改 CoreDNS 的底层数据，不够优雅。未来将修改为通过 CoreDNS 的 Dynamic updates API 接口进行，不过 CoreDNS 的这个API还在开发中，需要等待完成。） 单进程多接口问题的解决 上面的解决方案，在解决通过接口实现访问的同时，也将”单进程多接口”的问题一起解决了： 原SOA应用上k8s时，可以注册为标准的k8s Service，获取ClusterIP。此时使用应用名注册，和接口无关。 通过操作 CoreDNS，我们将该SOA应用的各个接口都添加为 DNS 记录，指向该应用的ClusterIP 当客户端代码使用不同的接口名访问时，DNS解析出来的都是同一个ClusterIP，后续步骤就和接口名无关了 欠缺微服务改造带来的限制 需要特别指出的是，DNS通用寻址方案虽然可以解决使用接口名访问和支持单进程多接口的问题，但是这种方案只是完成了“寻址”，也就是打通端到端的访问通道。由于应用没有进行微服务改造，部署上是依然一个应用（体现为一个进程，在k8s上体现为一个Service）中包含多个接口，本质上： 服务注册依然是以应用名为基础，对应的k8s service和service上的label也是应用级别 因此提供的服务治理功能，也是以k8s的Service为基本单位，包括灰度，蓝绿，版本拆分等所有的Vesion Based Routing功能 这意味着，只能进行应用级别的服务治理，而不能继续细分到接口级别 这个限制来源于应用没有进行微服务改造，没有按照接口将应用拆分为多个独立的微服务，因此无法得到更小的服务治理粒度。这也就是我在2018年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，在6月底对外公布了 SOFAMesh，详情请见之前的文章: 大规模微服务架构下的Service Mesh探索之路 。 DNS通用寻址方案总结 我们将这个方案称为”DNS通用寻址方案”，是因为这个方案真的非常的通用，体现在以下几个方面： 对使用者来说，通过域名和DNS解析的方式来访问，是非常简单直白而易于接受的，同时也是广泛使用的，适用于各种语言、平台、框架。 这个方案延续了k8s和istio的做法，保持了一致的方式方式，对用户提供了相同的体验 这个寻址方案，不仅仅可以用于Dubbo、SOFA、HSF等RPC框架往Service Mesh的迁移，也可以适用于基于HTTP/REST协议的SOA应用，甚至最传统的web应用（例如tomcat下部署多个war包）迁移到Service Mesh 我们也在考虑在未来的Serverless项目中，将Function的寻址也统一到这套方案中，而无需要求每个Function都进行一次服务注册 概括的说，有了这套DNS通用寻址方案，不管需要寻址的实体是什么形态，只要它部署在Service Mesh上，满足以下条件： 有正常注册为k8s Service，分配有ClusterIP 为实体（或者更细分的子实体）分配域名或子域名，然后添加到DNS，解析到ClusterIP 那么我们的DNS通用寻址方案，就可以工作，从而将请求正确的转发到目的地。而在此基础上，Service Mesh 所有的强大功能都可以为这些实体所用，实现我们前面的目标：在不修改代码不做微服务改造的情况下，也能提前受益于Service Mesh带来的强大服务治理功能。 — END —
-
发表了文章 2018-10-10
蚂蚁金服的to B开放
小蚂蚁说： “单一的人工智能或者区块链技术不足以支撑完整的金融业务形态的发展，我们认为的金融科技，在涵盖了这些新兴的金融技术（区块链、人工智能）之外，还包括IT基础架构升级换代的技术体系，包括大家熟悉的云计算和大数据以及金融级专属的技术，所以这是一个完整的支持金融业务的技术堆栈，而这些技术的集合能够与金融业务的发展建立如方程式般的关联度，让科技的产出变成可以量化的业务价值，这些才是金融科技的真正精髓所在。” 前言 在2018杭州云栖大会-ATEC金融科技开放峰会上，蚂蚁金服副总裁刘伟光提出了"数字化半径"的概念。 “从金融IT信息化到金融科技，我们用‘半径’来作区分。未来数字化银行是全方位的。数字化理念和基因，将贯穿银行的各个部门，甚至成为每一个人身边的工具。所以说数字化半径代表着银行未来业务增长迭代的半径和速度。半径这个词代表着覆盖的深度、广度。” 不仅是银行，所有的金融机构都面临着类似的挑战，以现有的技术基础、业务创新能力，显然还无法支持用户的新一代的随时随地需求。一些科技公司也注意到了这个断层，这些年的2B市场也在不断蓬勃发展。 蚂蚁金服副CTO胡喜 蚂蚁金服是最早一批提出技术开放的企业之一。蚂蚁金服副CTO胡喜在大会上进行了一次总结性发布，据介绍，在2015~2018三年间，从“互联网推进器计划”到“成熟一个开放一个”，蚂蚁金服的公布产品数量从5个增长到了80个，解决方案从3个发展到了50个。 他还宣布蚂蚁金融云升级为蚂蚁金融科技，实现了100%全面开放，包括三地五中心的容灾系统，BASIC技术（区块链、人工智能、安全风控、物联网、计算）及解决方案，和余额宝、花呗、财富号、小程序等业务能力。而未来将以“蚂蚁金融科技”为技术输出品牌。 完整的支持金融业务的技术堆栈 从2015年的蚂蚁金融云，到2017年强调分布式技术架构，在夯实技术基石之上，蚂蚁还在向更多应用和场景需求延伸。而今，蚂蚁常说2B模式是以业务、技术双轴为驱动的。目前已有80多个产品及解决方案，梳理来说，总有三类： 一类是金融科技产品，包括分布式中间件、分布式数据库、图数据库以及新发布的区块链BaaS平台等 第二是智能、安全、金融交易与交互等通用解决方案 第三是数字银行等垂直业务的行业解决方案。 蚂蚁金服方面表示，2018年重点升级的是分布式金融核心套件。据称，该方案不仅封装了分布式事务、通信、容灾、弹性伸缩、资金安全等多项经历实战验证的底层技术方案，同时融合了蚂蚁生态和业务场景，以及支持ISV与金融机构快速研发上线业务应用系统的能力。 “蚂蚁技术开放的目的不是为了销售软件，真正的目致力于用技术解决业务发展中的难题，用技术改变业务形态；用技术创造新的业务模式，与金融机构建立更为紧密的连接关系”。刘伟光表示，以此将蚂蚁的定位与金融IT商做区分。“蚂蚁金服与金融机构最早建立的连接是基于支付业务的合作，后来我们有了很多其他普惠金融类的业务，包括网商银行的同业合作，借呗、花呗的业务合作，如今，我们想增加一个新的连接纽带，就是科技。” 如果将中国银行业的黄金十年分为三个阶段，最早期是信息系统加金融，技术在金融行业的定位只是支撑型业务，业务部门提出需求，IT部门实现需求。这个阶段更准确的定义是“金融IT”。第二代是互联网金融时代，在这个时期，金融机构开始谈如何和互联网公司合作、场景渗透和生态获客。第三个阶段是智能金融，将人工智能融入到业务流程，用人工智能帮助交叉销售、降低人工成本，更多的是引领或者改变业务发展形态，脱离了相对被动的角色。 刘伟光指出，“单一的人工智能或者区块链技术不足以支撑完整的金融业务形态的发展，我们认为的金融科技，在涵盖了这些新兴的金融技术（区块链、人工智能）之外，还包括IT基础架构升级换代的技术体系，包括大家熟悉的云计算和大数据以及金融级专属的技术，所以这是一个完整的支持金融业务的技术堆栈，而这些技术的集合能够与金融业务的发展建立如方程式般的关联度，让科技的产出变成可以量化的业务价值，这些才是金融科技的真正精髓所在。” 金融机构+开发商生态共创，革新传统IT服务模式？ 刘伟光解释说，与传统的IT服务模式的区别主要有二。 区别一是出发点和关注点不同：IT服务商基本上面向B端，不太关心用户顶层战略，更关注科技战略和年度预算，“蚂蚁关心的不仅仅是科技部的战略，更关心的银行的战略，以及如何分解业务战略目标。” 因此，合作重点会有所不同。蚂蚁与南京银行联合发力互联网金融以及鑫云+平台；与西安银行等小型银行的合作注重移动战略；也帮助重庆农商行建设大数据平台以及智能风控平台；与台州银行合作移动端的建设，深化小微企业金融服务的过程；与常熟银行合作建设大中台支持大零售转型；与广发银行合作，则从前期的推动广发信用卡发展，到即将进行分布式核心业务平台能力的探索研究。以往的合作客户案例可章查看我们的以往文章《30家客户案例带你看蚂蚁金服全面科技开放》。 另外，业内人士也告诉过雷锋网，金融机构的定制化需求是一大趋势。而蚂蚁实现定制化需求的模式，与传统IT厂商有所区别。 胡喜接受采访时表示，这个特征在蚂蚁内部体系也存在。“我们内部建立了一个开源共建的体制，代码完全开放。其他业务的垂直BU自己也可以实现定制化需求。”面向外部时，具体的应用场景要求技术提供方对于业务非常理解和专业，所以他们尽量还是聚焦在通用性。 区别之二在于生态圈：“IT公司的服务模式就像盖房子，盖完一个接下一个，不会替开发商考虑销量问题，而蚂蚁除了建设一流的房屋，会帮助装修、获客销售，甚至运行维护体系的建设和培养等。”以移动银行为例，几乎所有银行都有手机银行，但是获客和营销以及数据运营一直是个难题。高科技的手机银行不是纯粹为了高科技，而是为了解决上述这些问题。 当下金融APP已经不只是单纯的金融服务平台，而是金融+生活的大平台，是创造更多的场景以及与很多现有场景建立连接。因此，除了技术赋能，蚂蚁金服常提的策略就是生态开放。 刘伟光表示，“2.0时期的能力主要是分布式架构、数据库、中间件等，相当于提供一辆车的发动机，各家的发动机只是性能优劣的区别而已。我们希望将技术与应用深度融合，在科技开放中秉承着应用驱动的原则，与金融行业的应用开发商（ISV）一起合作，真正提供一台整车的交付能力，向上沉淀，才能让科技和业务之间产生直接的连接，不只是只聚焦下面的基础技术架构层面，这也是我所强调金融行业的纵深度。” 科技开放步入金融机构数字化转型关键时刻 今天的中国金融机构正在面临数字化转型的拐点，一个值得关注的信号是，越来越多的金融机构主动拥抱科技战略，积极转型，并且是更加深入地采用各种措施加速数字化转型。我们今天看到的，是科技与金融业务越来越深度的融合。 其中关键是，就像CPU推动互联网科技进步，GPU推动AI集群技术落地一样，金融核心系统转型升级，将极大推动数字金融的发展进程，让业务核心系统可以无边界的支撑业务的发展。 刘伟光演讲中提到交流时几位银行客户的困惑，有人问“未来的CoreBanking系统是不是还存在？是否会变成业务能力工厂的形式存在？”或者，“Core Banking系统不进行分布式改造从而去支撑更多的业务类型，则没有出路。” 变革的当下，有迷茫者，也有坚定的前行者。 中国建设银行科技部总工程师胡宪忠称，现在建行已经没有核心系统，变成了完全组件化。“IT架构转型是数字化创新的基石，唯有创新才能快速进入市场，面对新兴的产业生态体系。” 他详细介绍了建行2011年初至2017年底的规划过程。初期，他指出，存在宏微观多因素驱动建行革新，“建行有十亿个活期帐户，每天有4亿笔交易。最高峰每秒钟有12000笔的吞吐量，系统非常复杂。这些东西放进一个信息系统的时候，要怎么在服务水平很低的情况下做无缝的衔接？” “这不只是核心系统转型，而是一个全业务范围的再造。要把建设银行的业务以结构化的方法重新定义，变成一个企业级的能力、打破孤岛的系统。” 再看另一个案例——招商银行一向是金融科技先锋军。近日招商银行APP7.0发布，据介绍，在App 6.0的微服务架构基础上，7.0对内部研发流程做DevOps（开发运维一体化）的变革。招行研发中心相关负责人告诉雷锋网，“传统方式自然也能做开发，但在微服务这种架构下施行DevOps，利用人工智能和大数据去改造研发流程，包括系统质量、投产数量、事故率的变化等。过往传统研发方向可能主要来自产品经理的构思，现在多了大数据来告诉我们怎么改进，每次迭代的有效性和速度也更能有所体现。” 蚂蚁金服与南京银行的合作也是一个典型案例，胡喜在采访中也称这是让其印象最深刻的一桩。他指出，监管要求金融机构自主可控，但是说得多，做得相对少，真正从主机上下移的银行、金融机构也不多。 “所以我们后来想到采用双核心机制，老核心继续运行，新核心启动起来，让老核心逐渐往新核心迁移。南京银行就是在做新一代互联网的核心，面向互联网渠道的客户。南京银行的项目非常关键，相当于你在另外一个地方，重新搭建了一个银行核心系统，存、贷、汇业务全部建立在新技术基础上。” 据雷锋网了解，去年阿里巴巴、蚂蚁金服与南京银行达成合作，在项目实施交付上，他们打破了传统IT项目中的流程和做法，不再用总包商、集成商、多方产品供应商组成多国部队联合作战的模式，而是采用一站式服务做法，敏捷开发以及DevOps的工具的大量运用，大大缩短项目开发测试周期，将互联网项目交付的速度带到了传统的银行中。 据称，他们用了不到5个月的时间，从“一张纸”到完成互金平台“鑫云+”的上线，而按照传统流程，需要一年以上。据称，上线半年，截至2018年6月底的最近8个月中，“鑫云+”平台新客户数达到390万，每日贷款额从1千万人民币上升至10亿人民币，贷款余额从1亿人民币增长至100亿人民币。另外，客户平均处理时间小于1秒，实现秒级放款。 所以，到了今天，金融科技不再只是单点应用，不只是依靠酷炫的科技的炒作，也不只是某些纯线上业务的背后的技术平台，而是真正进入金融业务由科技推动和引领的时代。毕竟，在创新转型时期，决定成败的关键，不是一只脚有没有踏入未来，而是另一只脚有没有从过去离开。 未来数字金融：随时随地随需 金融数字化转型的关键在于彻底的数字化服务能力和企业数字化基因。过去的银行重视线下网点建设，场所驱动；在互联网金融发展的时候，一部分银行也紧抓线上场景。 但场景即金融吗？场景确实是很明确的经营信号和范围，好处在于风控门槛降低，以及产品定义门槛降低，即获客的捷径。 蚂蚁金服表示，未来入口会细微化、隐形化，场景从需求而来, 场景更需要自己去建设。因为需要金融服务的不是场景，而是人。金融机构先要满足一个人的需求，才有所谓场景。 “比场景驱动业务模式更进一步的是——需求触发业务。未来的进化方向将会是，只要有需求，就能随时调用银行服务，甚至不一定需要在场景中。未来的银行服务都可能放在云端，伸手可得，金融服务得以摆脱时间、空间对物理网点的制约。未来的银行应该是秒申秒到、即用即走、有需求触发的银行”。 雷锋网AI金融评论此前报道，“场景可能是个伪命题，接口虚拟化是未来银行的进化方向之一。” 而这种移动化、碎片化的需求，要求着随时随需随地的服务能力，即足够深厚和广泛的数字化区间服务能力，提高金融核心业务平台支持水平。 未来，金融的业务能力，并不是单纯的技术问题或者业务问题，业务和技术是一个硬币的两面。拓宽金融机构的数字化半径，意味着从不同角度纵深、横向拓展的数字化服务和触达能力。 注：本文转载自雷锋网 — END — 蚂蚁金服官方唯一对外技术传播渠道 投稿邮箱：anttechpr@service.alipay.com 欢迎留言及个人转发，媒体转载请联系授权
-
发表了文章 2018-10-10
2.0 解析系列 | 一文详解新一代OceanBase云平台
小蚂蚁说： 9月21日，OceanBase 2.0 在云栖大会上重磅发布。我们将在接下来的时间里为大家持续推出 “OceanBase 2.0 技术解析系列” 文章，分别从 可运维性、分布式架构、数据可用性、性价比及兼容性 五个方面对OceanBase 2.0的产品新特性及其背后的技术原理进行深入的解析。 本文将带你全面解析新一代的OceanBase云平台，更多内容欢迎持续关注本系列！ 本文作者：笑言 现任蚂蚁金服OceanBase团队技术专家，2014年加入阿里巴巴，从事领域涉及分布式事务中间件、中间件高可用，目前主要负责OCP 2.0系统的建设工作。 前言 OceanBase云平台（OceanBase Cloud Platform，以下简称OCP）是一款专门用来管理OceanBase数据库集群的管控平台。通过OCP，可以一键安装、部署、升级OceanBase集群，监控集群的运行状态，创建和维护运维任务，并且对应用开发者透明。OCP伴随着OceanBase而诞生，至今已经从1.0全面进入2.0时代。 OCP 1.0由zookeeper、kafka、Jstorm、Hbase、OTS、OBAgent、obztools等十余个组件构成，各组件协同，在阿里巴巴集团内部，管控了超过5000个OceanBase服务节点，每秒处理监控指标超过100万次。 然而，功能和架构如此复杂的系统在向云转型的时候遇到了两个艰难的问题——部署成本高并且运维复杂。这两个问题对OceanBase的快速输出造成了巨大的障碍。在照搬集团内部技术架构的过程中，系统的表现甚至不如某些开源系统。 问题总是可以在历史中找到答案。英特尔公司成立之初主营业务是半导体存储器芯片，很多年来，英特尔就是“存储芯片”的同义词。然而几年后，英特尔在自己开创的存储器领域被 5 家来自日本的电子公司甩到了后面。 图为英特尔三巨头，从左至右分别为安迪·格鲁夫、鲍勃·诺伊斯和戈登·摩尔 英特尔的两个创始人格鲁夫问摩尔，“ 如果我们下台了，公司再任命一个新CEO，你觉得他会怎么办？” 摩尔不假思索地回答，“他会放弃存储器业务。”，“那我们为什么不这么做呢？”。所以，诞生了全球最大的处理器巨头。 那么，对于OCP团队来说，如果让我们重新来架构OCP 2.0的话，我们该怎么做呢？ 场景的变化 1. 基础设施的变化 阿里集团基础设施包括了若干自建独立机房，机房之间通过高带宽低延时高效骨干网络相连接，即使跨城的机房之间网络传输丢包率也很低。 构建于高质量基础设施之上的开源组件，比如zookeeper，可靠性很高。然而，对于大多数企业级客户，有些是租用第三方机房，有些不具备三机房条件，基础网络的可靠性也不高，延时不稳定，开源产品运行故障率很高，OCP的SLA无法得到保证。 2. 业务的变化 众所周知，阿里双十一所面临的高并发场景是极端的，需要投入大量的基础设施资源、人力资源来保障系统的稳定运行。而外部业务由于其差异性，往往对基础设施的投入成本比较敏感。OCP的近十个组件的部署成本很高。 阿里集团由于其业务需要，比如HBase、JStorm等主流的开源产品都有专门的团队维护，专业的技术力量为OCP系统提供了强大的后背。然后，在外部输出的时候，OCP系统显得孤立无援。 综上两点，若干开源组件依赖，对OCP的可靠性带来了挑战，也引入了较高的部署成本。 OCP 2.0的诞生 OCP作为直接面向应用开发者的在线系统，同时承担了超大规模OceanBase集群的监控和运维工作。在对接企业级业务系统的场景下，至少需要具备以下能力： 对于在线系统，需要提供持续且稳定的高可用服务 对成本敏感的企业用户，要求OCP在占用少量机器资源的同时，提供高并发访问 尽可能少的运维人员投入，要求系统能够实现无人值守 提供可定制、可扩展的产品能力，可在线升级 综上，OCP 2.0在架构设计上，进行了彻底的自我革命，完全抛弃了1.0时代对若干开源组件的依赖，OCP层面坚持去中心化的设计理念，将所有的状态信息集中到OceanBase数据库。 因此，带来的最直接的收益就是极大的缩短了服务链路，在架构层面保证了系统的运行质量，同时，去掉了开源软件的部署成本。 OCP 2.0解决方案 OCP 2.0由运维链路、监控链路、诊断链路、数据链路、高可用链路、基础设施等若干子系统。每个子系统又切分成数十个甚至上百个小服务，每个服务实现一个独立的业务逻辑，服务间弱依赖，带来了开发语言以及系统框架选择的灵活性。 1. 基础设施 考虑到外部场景的基础硬件多样性，OCP 2.0提供了统一资源调度层，将物理机、Docker、ECS等纳入资源池统一管理，提供标准化接口屏蔽底层差异，并通过规模化来降低总体成本。同时，标准化IT资源，有利于完成应用服务的快速伸缩。 OCP 2.0统一计算平台提供了标准化的计算能力、任务编排能力，可根据简单定制完成实时、半实时、周期、定时等各类计算需求。支持各种计算任务，包括shell、python、java、http等，能够满足常见的计算需求，还支持将应用自定义的java、python等代码投递到计算平台，实现按业务需求对系统扩展。 2. 高可用链路 OCP 2.0对安全问题非常重视，引入了流量控制保证系统运行时安全，引入了租户隔离保证业务之间数据安全。同时，系统引入全链路跟踪机制，监控完整的服务流转路径，尽可能缩短异常诊断路径，降低运维对人工介入的需求。 3. 运维链路 OCP 2.0承担了OceanBase集群、实例、租户、主机等维度的白屏化运维操作。不同于集团内部有DBA团队承担所有数据库运维操作，外部往往按照组织结构或业务部门来划分数据库实例，各司其职，因此OCP 2.0划分了系统管理员、应用管理员、应用开发人员三个角色，每个角色有各自的用户视角，每个角色承担部分运维功能，不仅符合用户行为，更增强了数据库安全性。 依托于统一计算平台，做到了运维任务的全程可监控。只要是运行于计算平台的计算任务，计算平台会分配一个独立的进程负责任务执行，同时，把运行时IO流、错误流实时推送到浏览器端，做到计算过程所见即所得。 4. 监控链路 OceanBase的监控对象包含集群、租户、服务节点、SQL等多个维度，包含上千个监控项，计算每一个监控项都会记录若干乃至上百条监控日志。OCP 2.0将监控信息存储到OceanBase数据库，可使用日志副本来尽可能降低存储成本。 OCP 2.0提供了灵活的监控指标定制能力。在以往的存储模型选型中通常会遇到宽窄表的选择，如果采用宽表作为监控存储模型，一旦监控指标发生变化，会造成锁表；如果采用窄表，可以较好应对指标变化，但是会造成储存空间的浪费，不够经济，并且监控指标变化会引起计算逻辑变化，系统维护成本高。OCP 2.0利用了OceanBase增量数据写内存、定期转储的特性，采用宽表作为监控指标存储模型，同时DDL不锁表。 5. 诊断链路 OCP 2.0将集团内部沉淀已久的智能数据库诊断优化产品以及集团DBA的数据库优化经验集成，以统一视角展示。提供了数据库资源的诊断与建议、SQL诊断与优化、慢SQL诊断等常用功能。 6. 数据链路 OCP 2.0提供了常用的数据备份、恢复、历史库等功能。并与ODC、OMS等系统集成，提供了数据导入导出、DDL导入导出，以及数据全量、增量迁移等功能，可做到在不停机的情况下，将mysql、oracle等主流关系数据库数据导入OceanBase。 结语 OCP 2.0的架构思路是去依赖、去状态，以及尽可能缩短服务请求的执行路径。在满足高并发、高性能、高可用的基础上，能够快速输出；并且开放了Open-SDK，给了应用参与到OCP插件开发、快速适配业务变化的能力。 架构是一种平衡的艺术，而最好的架构一旦脱离了它所适应的场景，一切都是空谈。OCP 2.0去掉了kafka、jstorm等计算平台，实时性相对变差了，但是仍然在可接受范围内，换来的是大幅降低了资源占用成本以及提升了系统可用性，总体来说，得远大于失。 OceanBase 2.0技术交流群 想了解更多 OceanBase 2.0 特性？ 想与蚂蚁金服OceanBase的一线技术专家深入交流？ 扫描下方二维码联系小编，快速加入OceanBase技术交流群！ 加入我们 【OB云平台研发专家/架构师】 岗位职责: 1. 负责大规模运维系统，比如自驱动平台或AIOPS的设计开发,包括部署、监控、备份、高可用、容器化等能力，服务云上和云下企业用户； 2. 带领一个研发小组，负责产品整体架构的设计、确定核心模块的功能实现方案和性能优化方案； 3. 参与平台架构的设计，主导设计底层模块，技术实现方案要兼顾性能、稳定性、扩展性和易用性。所有功能及异常通过数据驱动做到自恢复自优化； 4. 团队内外高效协作，确保前后端模块的协同工作，开发团队采用敏捷开发模式。 职位描述： 1. 大学本科或以上学历，计算机或电信电子相关专业， 3年以上软件开发经验或3年以上算法开发或应用经验； 2. 熟悉高并发编程，精通Java或Python或Go，熟练使用常用的web开发框架； 3. 对数据库系统运行熟悉，丰富的MySQL或Oracle 应用开发和表结构设计经验； 4. 具有一定的产品思维和管理团队的能力，能够带领团队一起实现自己的产品构想； 加分项： 5.对VLDB，SIGMOD等数据库顶级会议有解读经验的，对Oracle, Microsoft, IBM, Google, Amazon等公司所倡导的数据库潮流有跟踪分析经验的优先； 6. 有良好的问题排查经验，善于独立思考，有快速学习能力，不断突破技术瓶颈，乐于探索未知领域，在较大压力下保持工作激情； 7. 对数据驱动和算法应用有实战经验，有AIOps、自动化智能化平台开发经验尤佳 ； 8. 了解云平台，具备OpenStack / DevOps工程经验者优先。 【OB云产品研发专家/算法专家】 岗位职责: 1.需要理解业务，根据业务需求完善OceanBase云产品，包括数据库开发中心、自动化性能优化与诊断，容量和性能的分析预测，在线数据实时计算等等； 2.OceanBase驱动、工具研发，包括JDBC,SDK,API等； 3.进行数据相关的采集、存储、同步、管理等开发，基于数据做智能诊断，在数据采集、建模分析、产生决策、自动修复上形成闭环。 职位描述: 1. 丰富的Java开发经验，基础扎实，了解Java并发编程及性能优化； 2. 熟悉MySQL或Oracle等数据库的运行机制和架构体系； 加分项： 3. 对数据库原理有认识，对分布式数据库和NoSQL有研究，对分布式技术有深入研究者； 4. 对自优化、自决策方向核心功能模块开发、系统性能优化，比如SQL诊断与建议有研究者； 5. 数据驱动的模型与算法，熟悉聚类、KNN、决策树、贝叶斯、深度学习、增强学习等常用的算法和应用； 6. 有PaaS/SaaS/数据访问中间件产品开发经验优先； 7. 良好的沟通和团队合作能力， 较好的创新能力并能够主动推动落地。 可直接发送简历到 OceanBase-Public@list.alibaba-inc.com，我们等的就是你！ — END — 蚂蚁金服官方唯一对外技术传播渠道 投稿邮箱：anttechpr@service.alipay.com 欢迎留言及个人转发，媒体转载请联系授权
滑动查看更多
暂无更多信息
-
发表了文章
2018-10-12
专访蚂蚁金服mPaaS｜移动下半场，不仅仅是技术能力开放
-
发表了文章
2018-10-11
OSDI '18重磅解密：蚂蚁金服实时金融级分布式图数据库GeaBase
-
发表了文章
2018-10-10
SOFAMesh解决方案x-protocol介绍系列(1) ： DNS通用寻址方案
-
发表了文章
2018-10-10
蚂蚁金服的to B开放
-
发表了文章
2018-10-10
2.0 解析系列 | 一文详解新一代OceanBase云平台
-
发表了文章
2018-10-08
3年10亿怎么花？支付宝小程序公布生态孵化细则！
-
发表了文章
2018-10-08
29岁支付宝工程师告诉你：8年，如何从菜鸟到全球化团队leader？
-
发表了文章
2018-10-08
蚂蚁金服ATEC技术峰会：共探技术开放新生态
-
发表了文章
2018-10-08
2018 ATEC 金融科技开放峰会｜科技的引领，来自实践的力量
-
发表了文章
2018-10-08
30家客户案例带你看蚂蚁金服全面科技开放
-
发表了文章
2018-10-08
蚂蚁金服副CTO胡喜ATEC上宣布：蚂蚁金服技术全面开放
-
发表了文章
2018-10-08
Basement 后端云服务正式亮相云栖大会！
-
发表了文章
2018-10-08
现场剪光缆！ATEC上支付宝模拟自断一半服务器，26秒一切恢复正常
-
发表了文章
2018-10-01
预践数字金融：详解蚂蚁金服分布式金融核心套件
-
发表了文章
2018-09-27
蚂蚁金融科技：两大发布，实力开放
-
发表了文章
2018-09-26
迎双11十周年，OceanBase 2.0挑战新巅峰
-
发表了文章
2018-09-25
马云怒赞的93年网红区块链工程师，教你如何用3年时间实现逆袭
-
发表了文章
2018-09-25
让算法工程师变身街舞达人，蚂蚁金服的这个比赛绝了
-
发表了文章
2018-09-25
蚂蚁金服AI首席科学家漆远：用AI和爱让我们遇见更美好的未来
-
发表了文章
2018-09-25
首发｜蚂蚁金服副总裁芮雄文：首次公开两大终端核心风控技术
滑动查看更多
暂无更多信息