Dyn的CTO Cory Von Wallenstein，主要负责公司IaaS平台技术的决策、创新和发展的方向的制定。近日他在Wired上撰文给大家描述省时省力的系统升级之路——黑暗架构(Dark Architecture)。以下为译文：
任何公司目标都是业务的增长，但是增长需要不断的衍化公司的每个部门，其中不只是你的技术基础设施。许多企业一直使用着非常原始的途径去完成这个衍化，虽然这里存在着极为简单的解决方案。
而公司升级其基础设施及系统架构一般出于以下3个原因：
为了规模——以获得当下十倍或百倍的容量
为了性能——试图移除一个系统瓶颈，让工作的执行更加快速
为了解耦——为了获得更好的可靠性及可维护性，当然也为了将来的扩展做努力
早先的方法属于全盘否定类：首先制定一个3个月的计划，然后开发人员开始全力以赴的打造新系统，希望3个月后能顺利完成。事实上经常出现的情况就是3个月变成6个月(不可避免的比预期时间要长)，而业务从老系统迁移至新系统也面临着非常高的风险。当新系统100%实现老系统所有功能后，遗留的旧系统便只能被废弃。
鉴于这六个月的开发时间里缺乏优先顺序及旧系统的其它改进，业务毫无疑问的丧失了灵活性。这种更新方式就像是“全部”或“一无所有”的命题，并且直到开发团队完成新系统的建设并且将所有业务转移到新系统，这段时间内对业务的提升基本为零。而面对来自客户的抱怨，技术团队的士气也一滑再滑。这种方法需要改进的地方主要归结于3个方面：
立刻给客户带来价值——我们没必要一直等到整个新系统完工并投入使用再实现价值
减少成品引进的风险——我们需要避免“全部”或“一无所有”的迁移计划
保持业务提供灵活性——可以选择优先级，最少要保证核心价值的及时交付(如果可以选择的话，我们要做到最快的解决并交付相对重要的解决方案)
针对以上解决方案：黑暗架构的实现途径
黑暗架构(Dark Architecture)不仅是一种思想，同样还是个技术解决方案;用以解决规模、性能及耦合问题，黑暗架构不仅让硬件通向成功而且可以让员工有一个清晰的思维。可以通过以下途径实现：
优先提升系统中的工作流，而不是改变系统的组件
并行运行老系统及黑暗架构
给两个系统同时发送输入数据，收集输出数据，对比输出结果，然后抛弃一个
使用暗黑架构途径，运作方式将如下所示：
1. 在接触代码与系统之前，先按照以下顺序优化系统中的数据流：短板、机遇、业务价值或者其它经验证后对业务有意义的事情。
2. 于其着眼考虑组件相关(比如使用Cassandra替代原系统中的MySQL)，不如考虑流系统(比如，为顾客X执行一次通配符查询类型图渲染大约需要40秒，而使用其它图渲染类型要快的多)。这个步骤能让你看到系统中的弊端所在，所以你可以首先聚焦这个瓶颈的解决方案，然后再考虑其它的问题。
3. 如果使用流优化优先(假设优化的功能占整个系统的2%)，事实上下一步做的并不是直接建立功能。取而代之的是为这些功能建立相关支架，让系统可以同时使用两个不同的方式进行计算(为了对比输出结果，有差异时做记录)。
黑暗架构具体实践方案
从实际情况出发，这可能是复制一个网络服务调用(旧的和新的)或者是复制数据库交互调用(同样一新一旧)，然后对比返回值，如果存在不同则将其记录到一个文件或者服务器又或者是消息总线中。
在输入/输出支架就绪后，你就可以着手功能的建立。实现系统中最短板的2%功能，就绪后，将其投入产品中的黑暗架构。它将会与旧系统一起接收产品的输入数据，虽然最后它的计算结果会被抛弃，但是在这个过程中我们可以与旧系统的输出值进行比较。如果输出的结果不同，记录并进行检查。这让你可以更熟悉你的新系统，并且在具体操作中获得一些实际经验。
一旦确定新的系统可以正常工作并且达到了渴望的性能或者是扩展性提升，将输出转换成新的系统。这样，实现的只是系统中2%最短板的功能，其它功能则沿用旧系统的遗留。如此等于改动2%的功能，花费了一小部分时间就交付了整个新系统的价值。
使用黑暗架构得到的收益：
士气高昂——有什么比技术人员看到自己成果很快被投入使用来的更振奋人心?
客户肯定——他们头痛的问题被解决了
降低风险——在项目重写的过程中，新系统已经得到实际验证
下面看一下有更多高优先级流需要优化的情况——占整个系统的20%，使用黑暗架构途径，业务将很快的发现自己的方向：
持续更新流，直到系统100%都被迁移
对剩下的80%功能与业务优先进行评估
如此可见黑暗架构的强大作用，在最短时间解决系统短板的前提下还拥有选择更高的灵活性，可以从容对业务优先进行处理。
