治疗白癜风专科医院 https://baike.baidu.com/item/%E5%8C%97%E4%BA%AC%E4%B8%AD%E7%A7%91%E7%99%BD%E7%99%9C%E9%A3%8E%E5%8C%BB%E9%99%A2/9728824?fr=aladdin阿里妹导读：DataWorks是阿里巴巴自主研发，支撑阿里巴巴经济体99%数据业务建设和治理，每天数万名数据开发和算法开发工程师在使用。
从年起步到目前的版本，经历了多次技术变革和架构升级，也遗留了大量的历史包袱。技术的创新和业务的发展，相辅相成但也互为掣肘。存在需求接入慢，代码牵一发而动全身，环境复杂等问题，沉疴已久。历次迭代均未从根基上升级DataWorks，仅仅是一些性能提升、工程结构的优化，减少了重复代码等，并未促成根本性的技术革命。
本文将探讨如何通过当前大热的微服务架构，来改变DataWorks平台的现实问题，从繁杂的工程中探索出一条切实可行的技术架构变革之路。
一、痛点
让我们先来谈谈DataWorks当前遇到了哪些痛点，这些痛点是倒逼着我们进行技术变革的源动力。
1.1沉重的历史包袱首先要提的就是历史原因遗留的各种问题，DataWorks历史上多个版本同步开发，前后端技术栈多次变革，应用一旦上线就很难废弃，一个对外暴露的api，很可能是5年前开发的，但依然有业务在依赖，通常情况下连这些古老业务的负责人都找不到了。当我们的服务正常运行的时候，无人搭理，一旦下线，则可能不知道从哪儿跳出几个用户前来投诉。页面上的功能同样如此，有时候只是过去不知道哪位同学开发中引入的一个bug，但也因为我们的用户基数庞大，而变成了真理。历史上曾经出现过的隐藏的很深且用户寥寥的功能点都有自己的忠实拥趸，一旦被我们的开发不小心忽视而做丢了，就会迎来投诉和工单，所以DataWorks平台不愧是千锤百炼磨练出来的大数据开发平台的标杆，朴素的界面之下隐藏了无数细致入微的功能点。如果想重造这么一个被阿里巴巴经济体无数数据开发工程师验证（折磨）过的数据开发平台，都要好好考虑一下这十年来我们的平台到底经历过了什么。1.复杂的软硬件环境DataWorks面临的运行环境放眼整个阿里巴巴经济体都是及其罕见的复杂，为了混合云（即专有云）这种私有独立且封闭的环境，三合一版本之后我们必须放弃依赖弹内成熟的中间件体系，只能寻找那些同样在三个环境下都存在的技术来支撑。也因此，很多在某个环境下缺失的依赖，如果我们无法用开关的方式搞定，或者我们判断其复杂度不高，就会通过自研或者去依赖一些开源的体系来解决问题。而公有云上各种网络环境的问题几乎都要靠人肉去排查，从每天居高不下的答疑量上就能看到我们受环境问题的影响是多么耗费人力。除此以外，前不久中美 带来的影响也传递给了DataWorks平台，运行环境需要匹配国产芯片，我们的进程不但要运行在X86指令集上，同样也要能运行在基于ARM指令集的国产芯片上。同时为了满足部分中小企业用户的购买欲求，敏捷化也是我们需要去裁剪设计的。DataWorks平台虽然庞大且复杂，但在种种更加复杂的软硬件环境下，也同样需要能够做到灵活轻便，便于随时随地的拆散组合轻装上阵，以满足不同业务场景下用户的期望。因为挑剔的用户一贯希望用最少的钱购买到最合适的解决方案，DataWorks的竞争力显然也要从灵活且具备演变能力上寻找未来。1.牵一发而动全身工程之间的复杂关联一直是传统SOA（ServiceOrientedArchitecture：面向服务架构）发展到一定规模后的噩梦，无论最初的设计是多么合理，多么领域清晰，一旦经历需求的积累，规模的扩张，人员的交替，都将逐步或多或少的面临着边界模糊的问题。最典型的例子就是单体服务之间的RESTful类型的API，往往这些API的Schema只能增加元素而不能减少，因为被依赖者并不知道有多少其他服务正在依赖这个接口，也许某一天某个服务从沉睡已久的服务器中被唤醒，结果发现你的API的Schema变了，那么一定会把你喊回来修回原来的样子。前后端分离架构下，这类问题更加突出，所以有的前端同学为了减少schema变动带来的影响，干脆让后端透传一个大字符串，即使里面夹带了私货，也不会使得页面莫名崩溃。DataWorks平台也正在经历着这一过程，发展到一定规模后，每个功能的改动都要小心翼翼，生怕对其他模块造成未知的影响，或者有时候我们需要把大量时间投入在调研清楚改动带来的影响上，就算这样严防死守，也依然可能有漏网之鱼，最后功亏一篑，一个故障单就可能把为之付出的努力付之一炬。1.需求变更和频繁发布除了工程架构上的问题，同样存在问题的还有众多开发者在合作方面产生的问题，gitlab帮我们解决了版本之间的代码冲突问题，但并不能解决产品发布周期上的冲突。当多个需求都要对外发布上线，尤其在混合云，需要按月为周期产出大版本，我们一边要快速上线新feature，一边还要按照类似瀑布模型的方式将这些功能打包进专有云版本。弹内、公有云、混合云的发布节奏截然不同，众多feature按照不同的节奏要出现在不同的版本迭代中，过去的熔断机制，更加剧了大家在窗口期集中发布而产生的风险。在SOA中的一个单体服务上，N个开发者开发的M个feature，按照什么样的间隔组合发布上线，使得发布的节奏既不过于频繁，也不会因为发布频次太少而使得版本跨度太大。如果这M个feature之间又存在依赖关系，则进一步放大了发布频次增减之间的矛盾。1.5国际化带来的问题国际化的问题向来不简单，时区、夏令时、语言、习惯、本地化图标等等，对于DataWorks这样一个遍布全球0个region的平台来说，这里面的水深的很。我们团队在国际化方面沉淀很多积累，并且将这些优秀的经验对外开源：
