上一节的最后，我们讲了阶段二可能面临的问题，如果公司想探索互联网模式，会遇到的问题。
例如有的企业推出互联网理财秒杀抢购，原来的架构无法承载近百倍的瞬间流量。
有的企业对接了互联网支付，甚至对接了国内最大的外卖平台，而原来的ESB总线，就算扩容到最大规模(13个节点)，也可能撑不住。
有的企业发现，一旦到了互联网大促级别，Oracle数据库是肯定扛不住的，需要从Oracle迁移到DDB分布式数据库，可是怎么个迁移法，如何平滑过渡，心里没底。
其实互联网模式并不是每家企业都需要经过的阶段，但是很多传统企业头部公司乐意探索的方向，例如工业企业有工业互联网，零售行业有新零售，金融行业有互联网金融等。
一、云原生体系演进阶段三：探索互联网模式，优化产品体验
1、互联网模式的特点
有一种误区认为互联网模式就是做一个网站，或者做一个APP。吴恩达在AI Conference的讲座中，提到了他对互联网公司的理解。商场+网站≠互联网公司，也即如果你是一个传统的商场，仅仅是做了一个网站，那不叫互联网化。
真正标识一个互联网公司的，有以下几点：
01 A/B测试，让数据说话
你的网站和APP设计成什么样，是你们一层层汇报，然后让老大决策么？大老板不一定了解客户的偏好，而主观认为的偏好，实际测试的结果往往大相径庭。所以要让数据说话，通过在线测试方案的结果，得出最后的结论，即便做不到迅猛提升，但可保证每次的修改都是正向的。
02 更短的周期
你的应用迭代速度必须足够快，而且根据数据的反馈，不断小步快跑，这需要组织和流程有很强的适应能力。和传统公司几个月升一次级不同，互联网公司几乎每天都升级，当你打开各种APP的时候，你会发现界面动不动就改了。
03 工程师和PM做决策
如何才能快速上线呢？如果每次上线都要一百多人开大会，让老大做决定，那肯定快不了。应该让工程师和PM做决策，他们才是真正听得到炮火的人，需要让他们独立负责一块内容，独立决策，独立上线，独立负责，所有的PM并行工作，才使得更新速度飞快。
二、互联网模式如何解决第二阶段的问题？
互联网模式不仅仅是一个网站和APP的事情，我们还是从企业架构的五个方面来依次阐述。
1、业务架构：架构微服务化，侧重服务治理能力
阶段二的服务化是按照业务领域进程拆分的，而互联网模式下，我们会遇到性能问题，因而需要进一步的拆分。假设第一个阶段我们拆分出来了订单服务，大促的时候，订单服务最容易出现性能瓶颈，我们就以它为例子。性能问题的常用解决方案有：数据库读写分离，数据库分库分表，使用缓存。就像下面图展示的一样，从单一的数据库→到数据库读写分离，缓存使用Memcached→到数据库使用分布式数据库，缓存使用Redis。每次基础设施改变，影响所有业务方，耦合严重，修改复杂。
为了解决这个问题，常用的方式是纵向分层拆分。
原子层generic：将数据库缓存操作封装在这一层，提供原子化接口
组合层compose：组合多次调用，实现复杂的业务逻辑，封装公共业务逻辑
controller层：实现特定场景的业务逻辑。
有的时候，当并发量再高的时候，还会进一步拆分。
例如上面的Order-compose服务中，有两部分逻辑，他们的高并发场景完全不同。
一部分逻辑是订单生命周期的管理，也即核心交易逻辑，这部分主要是写入，而且和交易相关，是需要事务能力。另一部分是订单关联状态查询，这部分主要是读取，关联的表比较多，但不需要事务能力。这两部分处理高并发的策略不同，应该拆分出来。
其中Order-Center主要处理订单生命周期的管理，里面涉及状态机，分布式事务，分布式数据库分库分表等。而Order-Searcher主要用于关联查询，如果用分布式数据库，很难找到合适的分库ID，因而使用ElasticSearch，可以各种关联查询，但是不需要事务，只读性能高。
当服务拆分的粒度比较细了之后，就需要服务治理的能力。
第一、服务依赖的管理
就是一个服务到底调用了哪些，被哪些服务调用。如果依赖管理混乱，就会比较痛苦，比如你要发布一个应用，可能不知道该应用被谁依赖，是否有一个特别关键的应用在依赖于我这个应用，我升级了以后是否会引发关键业务的不稳定，是应该白天发布，还是凌晨发布。
第二、调用统计问题
对于调用记录有一个统计和告警。例如接口突然调用失败率增高，接口突然时延增长，都应该及早发现，而不能因为因为一次发布引入一个bug，导致时延变长但无人知晓，等到流量一来，直接就可能压挂了。
第三、服务之间要设定熔断，限流，降级策略
一旦调用阻塞应该快速失败，而不应该卡在那里，处于亚健康状态的服务要被及时熔断，不产生连锁反应。非核心业务要进行降级，不再调用，将资源留给核心业务。要在压测到的容量范围内对调用限流，宁可慢慢处理，也不用一下子都放进来，把整个系统冲垮。
2、技术架构：基础设施容器化，统一微服务框架和工具链
为了解决服务治理的问题，需要配备相应的工具链，也即技术架构的部分。
在这个阶段，要实现微服务框架与开源技术栈的统一。一开始微服务做的比较混乱，有用Spring Cloud，有用Dubbo，需要一个统一的开源技术栈。另外，还要构建一个持续集成的平台，通过Agent和虚拟镜像部署软件包。
统一微服务框架之前，我们情况是这样的，一开始用服务注册服务发现，还是比较简单的。后来发现，还需要分流、需要降级、配置中心、认证鉴权、监控统计等，在业务代码之外加的越来越多，大家的代码写得到处都是，而且依赖于不同人的水平不一样，这就是一个当时遇到的问题。
后来我们就把它抽象成为了一个Agent，这个Agent在程序启动的过程中，通过jar直接带起来，使得统一的服务框架组件在Agent里面实现，并且提供统一的界面进行配置，这样业务方可以只写业务代码，基本上就搞定了这件事。
服务数目的增多，对运维又造成了很大的压力，原来是基于虚拟机镜像来构建应用运行环境，因为部署的应用越来越多，我们发现虚拟镜像的模板越来越多，会出现上千个无法复用的模板，好像每个小组织都有自己的一个东西，毕竟它还不是一个标准，所以接下来我们就拥抱了容器的标准。并且Auto Scaling原来是基于虚拟镜像的，现在使用Kubernetes来做。Kubernetes作为统一的对接资源的编排平台，无论是Vmware上，还是KVM机器上，还是物理机上，公有云上，上面都可以有Kubernetes统一平台。这个时候只需要对Kubernetes下发一个编排，就可以实现跨多个地方进行部署。在基于虚拟机的运行环境和PaaS中间件之外，基于Kubernetes也可以有自己的容器镜像和运行环境，以及基于容器镜像PaaS中间件。
3、数据架构：个性化推荐与精准营销，业务融合数据，数据驱动创新
上一个阶段的数据架构，还是将企业的运营情况通过BI报表实时的反馈给领导层，但是仍然需要领导层根据报表，下决策来调整业务。没有和业务真正的结合。到阶段三，数据和业务要真正的融合，实现数据驱动业务创新了。
第一种方式是A/B测试，通过它来优化产品体验。前面咱们讲过了埋点数据的收集，基于埋点数据，我们可以做用户的行为分析，事件分析，漏斗分析，留存分析，粘性分析。对于每一个不确定的Release版本，可以通过A/B测试来决定用户到底喜欢哪个样式。
第二种方式是建立标签体系。给用户打各种标签，从而根据标签进行推荐与精准营销。通过标签建立用户画像，并根据用户画像进行推荐。
第三种方式是提供接口给业务方调用。例如供应商系统需要对供应商进行评级，供应商评级需要供应商的商品销售数据、评论数据、退货数据、质量数据，供应商采购的交期数据等等。数据中台可以提供接口给供应商系统。
4、研发流程：DevOps流程，一切即代码，不可改变基础设施
微服务化之后，对部署上线的流程也有很大挑战，服务的数目会非常多，每个服务都独立发布，独立上线，因而版本也非常多。原来基于虚拟机镜像的部署也遇到了问题，是因为虚拟机镜像实在太大了，动不动几百个G，如果一共一百个服务，每个服务每天一个版本，一天就是10000G，这个存储容量，谁也受不了。这个时候，容器就有作用了。
1）容器作用之一就是环境交付提前，让每个开发仅仅多做5%的工作，就能够节约运维200%的工作，并且不容易出错。
镜像是容器的根本性发明，是封装和运行的标准。原来开发交付给运维的，是一个war包，一系列配置文件，一个部署文档，但是由于部署文档更新不及时，常常出现运维部署出来出错的情况。有了容器镜像，开发交付给运维的，是一个容器镜像，容器内部的运行环境，应该体现在Dockerfile文件中，这个文件是应该开发写的。
此时从流程角度，将环境配置往前推了，要求开发完毕之后，考虑环境部署的问题，而不能当甩手掌柜。运维组只要维护容器平台就可以，单个容器内的环境，交给开发来维护。
这样的好处是：虽然进程多，配置变化多，更新频繁，但对于某个模块的开发团队来讲，这个量是很小的，因为5-10个人专门维护这个模块的配置和更新，不容易出错。如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大非常多。
2）容器的另外一个作用，就是不可改变基础设施。
容器镜像有个特点，就是ssh到里面做的任何修改，重启都不见了，恢复到镜像原来的样子，也就杜绝了原来我们部署环境，这改改，那修修最后部署成功的坏毛病。
因为如果机器数目比较少，还可以登录到每台机器上改改东西，一旦出了错误，比较好排查，但是微服务状态下，环境如此复杂，规模如此大，一旦有个节点，因为人为修改配置导致错误，非常难排查，所以应该贯彻不可改变基础设施，一旦部署了，就不要手动调整了，想调整从头走发布流程。
5、组织架构：研发和运维融合，应用交付提前到开发，应用治理下沉到运维
到了微服务阶段，实施容器化之后，原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？
这就不是技术问题了，其实这就是DevOps，DevOps不是不区分开发和运维，而是公司从组织到流程，能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。
其实开发和运维变成了一个融合的过程，开发会帮运维做一些事情，例如环境交付的提前，Dockerfile的书写。运维也可以帮助研发做一些事情，例如微服务之间的注册发现，治理，配置等，公司的每一个业务不可能都单独有一套框架，可以下沉到运维组来变成统一的基础设施，提供统一的管理。
至此，整个云原生体系建设，才算基本完整了。
●相关阅读 ●
● 如何建立以业务为核心的云原生体系（上）
● 如何建立以业务为核心的云原生体系（中）
Nebulogy 品牌介绍
Nebulogy致力于通过云原生理念，帮助企业构建PaaS平台，提高开发资源利用率，满足应用快速上线和迭代需求，助力企业实现真正应用云化、业务互联网化。
网站：www.nebulogy.com
电话：400-105-0300
