技术方案如何支持业务发展-----更快的迭代开发速度、更高的并发和性能、高可用稳定的架构、低成本和自主可控

1. 更快的响应市场和用户需求

案例一：更快地获得市场

描述：2008年iPhone进入中国时需要与中方两家运营商——中国联通和中国电信进行合约机销售合作。中国联通的整个系统是集中式的架构，所以只需要修改一个系统，全国所有省份都可同步修改。而中国电信的系统架构则是“诸侯制”式，每个省份有自己完全独立的架构，所以改完一个省后还要改另一个省。这种架构的后果是让中国电信足足花了10个月才改完全国的系统。但在这10个月的时间内，就让所有高净值的用户流失到了中国联通的186号段，甚至也让中国移动的全球通用户都流失到了中国联通。中国电信错失商机。

方案：通过建立一个技术统一的技术中台，可以让企业在标准一致的通用能力的基础上进行自由灵活的前台订制化能力，让企业可以更快的适应市场的和用户的需求。MegaEase就是提供这样的技术和能力，这相当于现代战争中的空中飞机、地面火炮以及海上航母的作战群。

收益：通过一个自顶向下拥有精良设计的共享能力平台，达到技术能力的复用和沉淀，能够在一个月以内快速适应变化的市场和用户的需求。

案例二：更快更高频地发布功能

描述：某银行的产品和功能发布需要经历从需求调研，开发，测试和上线的“瀑布型”软件开发过程。其中需要协调很多的团队和资源，有非常复杂的软件开发过程的管理和协作成本，导致整个开发过程以月甚至以年为单位。

方案：MegaEase提供的方案通过分布式微服务架构，可以做到，把一个大功能变成若干个小功能，开发团队可以并行开发且并行上线，把一个大型的项目分解成简单、独立的功能，以碎片化的方式开发和上线。

收益：软件产品的发布周期从月到天，发布方式由串行并为并行，发布次数从一月1-2次变成一天多次。

案例三：快速安全地获得用户的反馈

描述：某互联网公司上线一个推荐系统和一个营销方案。开发团队投入10多个工程师，辛苦忙碌2个月，上线后，用户反应平平，没有任何市场效果。这样导致企业“试错”的成本极高，且非常影响团队士气。

方案：对于很多用户侧的需求来说，基本上没有人能够代替用户，无论是QA（测试）还是PM（产品经理）。也就是说，一些重要的功能在开发前期就需要有用户参与并进行反馈。MegaEase提供的灰度发布可以安全地对一部分用户进行发布，在早期获得用户反馈，让开发的功能更容易成功。

收益：极大降低企业的“试错”成本，无论是资金投入成本还是时间成本。

2. 大规模用户在线活动

案例一：大规模的线上用户营销活动

描述：因为要获得市场和用户，商家会经常进行多种市场营销活动。像“双11”、“带货直播”、“秒杀”、“抽奖” 等营销活动会有大量用户参与，且大部分是线上参与。这些在线的营销活动比线下需要支撑的人数更多和花样更多，如果后台系统无法支撑，就会流失用户以及销售订单。而更为糟糕的情况是这些用户和订单可能会进入到竞争对手那边。

方案：通过高并发流量调度，资源弹性伸缩，关键系统保障，性能调优等技术手段来支撑这类活动。

收益：百万级以上的在线营销活动，获得用户和订单的同时获得强有力的市场竞争优势

案例二 ：更为先进的营销模式

描述：对于现代商业，基本上来说都是围绕“拉新”，“留存”和“变现”三个阶段，这三个阶段，也是企业新型数字化转型的三大命题，我们需要通过营销或是合作的方式获得流量来拉新，通过产品的用户体验和服务让用户能够留存下来，最后才是变现。几乎所有的用户都会把时间花在手机和线上。所以，我们需要我们后台的IT基础设施能够进行转变以支持线上的这些营销模式。

方案：通过接入第三方流量平台，或是自己的“秒杀”或是“购物节”等相关的营销活动，以及实时的推荐系统能够让整个销售过程更为的流畅。这需要支持高并发的系统以及流量调度的基础设施。

收益：可以随时进行用户营销，提升用户转换率。

3. 整体系统稳定性SLA提升

案例一 ：降低故障的影响面

描述：某酒店预订网站在2015年5月27-5月28日因为部署系统问题“宕机”近两天。2015年9月1日，某云厂商因为升级安全软件，导致用户系统命令及可执行文件被删除…… 等等。很多互联网公司，无论大小，因为开发速度过快，软件带着bug上线，导致大面积用户故障的事时有发生，给公司带来非常重大的商业损失。

方案：通过灰度发布可以有效地降低故障的影响面，通过一小批用户得到上线的功能验证后，再进行整体发布。

收益：减小发布风险，加快开发速度，杜绝大面积故障。

案例二：降低故障的修复时间

描述：某银行在处理用户故障时，需要花费30分钟-60分钟才能定位故障点，而且，在处理修复故障的手段上非常有限，只能在F5上进行限流，或是对相关服务进行重启的高危操作。故障时间过长不但导致商业上的损失，还导致公司的公关危机。

方案：当故障来临时，需要尽快的修复故障。尽快的修改故障，恢复系统，需要两个手段，一个是能够快速定位故障，另一个是能够快速解决，这需要可以解决故障的控制系统。MegaEase的监控系统把所有的监控数据全部关联在一起，可以快速地分析服务调用链，资源和中间件使用的关系，并通过流量控制系统，服务治理以及资源调度等控制系统进行故障的快速甚至自动化恢复。

收益 : 故障处理时间从小时级降到分钟级，对于常见故障，可以在1-2分钟内修复。

案例三：防火胜于救火

描述：某公司的系统在经过一段时间运行后，因为代码和数据的变化，导致系统的性能在不断下降，但是这个下降并没有被运维人员观测到。当某天数据量达到一个临界点时，整个系统真正宕机崩溃，引发一个大故障。在面对这个故障的处理过程中，运维团队发现代码无法马上进行优化，而需要更多的资源也不足，整个过程进入了焦燥、慌乱和被动的情境。

方案：一旦故障发生的时候，整个工程团队只能陷于高压力、紧张和被动的状态，在这样的状态下都无法很好的解决问题，通过MegaEase提供实时“体检”功能，容量评估计划，以及全链路压力测试能力，能够帮助用户进行日常的故障演练，不但可以做到“防火”，而且还能做到在故障发生时可以从容应对。

收益：通过全链路压力测试可以找到系统的性能瓶颈点。通过系统体检可随时跟踪系统变化，随时观察整个系统的运行情况，并能快速找到有问题的系统和节点，把系统优化做在故障前面。

案例四：与故障共存

描述：对于很多故障来说，都是从一个很小的故障蔓延开来的，千里之堤，毁于蚁穴。某电子商务互联网公司，因为一个“用户徽章服务”的代码问题，导致一个关键中间件发生故障，造成整个用户系统故障，而用户系统故障导致了整站故障。另外，某公司基础资源因为硬盘损坏，导致服务运行出错，该服务出错，导致“多米诺骨牌”效应，在短短10分钟内，故障蔓延到整个订单服务不可用，造成重大的经济损失。

方案：通过MegaEase提供分布式系统冗余设计，故障隔离，以及流量治理，服务治理，服务弹力和容错设计，服务和资源调度、自动化弹性伸缩等手段，把故障当成正常的功能直接设计在系统中，可以做到即使有故障发生，整个系统也可以平稳运转。

收益：整个系统可以容忍故障，在20%的节点出现故障的情况下依然可以正常运行

4. 成本节省以及自主可控

案例一：专注自己的业务

描述：微商、出海建独立站、独立开发者、独立的工作坊或是一些小型公司，他们在商业行为需要更为专注自己的核心应用开发以及塑造用户体验，而后端的架构非常复杂和高门槛，需要一个专业的团队进行架构和运维，这会导致企业花费更多精力管理和维护，包括需要花很高的成本组建一支高技术团队。这给企业制造了巨大无比的成本。

方案：通过使用MegaEase一整套的后端架构的开发运维框架可以极大地降低后端的开发和运维门槛， 甚至可以委托MegaEase全权托管。

收益：专注于开发核心应用以及重塑用户体验，而不用管理维护后端

案例二：多种省成本方案”齐头并进“极大降低成本

描述：某互联网公司一年在云上的花费大约是2500万人民币，因为技术架构和运维管理不合理，导致了资源利用率和使用有非常大的浪费。这其中包括的浪费有：1）60%以上的云服务存在利用率过低的情况，2）技术架构存在不合理的情况，对云资源有很大的浪费，3）没有良好的容量规划，以及技术优化，导致需要消耗更多的资源，4）使用完的资源没得及时释放，5）过度依赖云厂商导致使用费连年上涨。等等。

方案：通过下面一系列的方式，我们可以做到成本极大的下降：

• 首先，通过架构优化和技术调优的手段进一步提升资源利率，并降低资源使用成本。
• 其次，通过前期开源软件自建非核心业务系统，后期完全自建，以及托管运维的方式降低开发运维成本。
• 最后，通过共享共建、服务共享的方式进一步摊低成本。

收益：该公司整个IT基础设施的成本从2500万/年降低到了1000万/年。

案例三：自主可控，不被厂商锁定

描述：某银行长年使用IBM、Oracle的技术产品，并且很多核心业务系统或是技术核心系统也由完全不同的供应商提供。多个供应商之前完全没有相关的技术标准以及符合企业自身的技术规范，都是自己主导的专用技术标准，目的就是为了锁定用户，并且这还导致最终落地的产品只能是一个系统集成拼湊出来的东西，自己完全控制不住整体架构，最终也没有相关的技术能力。

方案：系统架构和系统集成最大的差别在于，系统架构是一个基于标准开放的技术（如主流开源项目）有行业技术标准规范和最佳实践的，有顶层设计方案的整体架构。MegaEase不但提供整体开放符合业界标准的技术规范和技术方案，同时也提供完整开放的开源技术产品。

收益：不被技术绑架同时不光获得了服务，技术团队还获得相应工程能力