网易考拉(以下简称考拉)是网易旗下以跨境业务为主的综合型电商，自2015年1月9日上线公测后，业务保持了高速增长，这背后离不开其技术团队的支撑。微服务化是电商IT架构演化的必然趋势，网易考拉的服务架构演进也经历了从单体应用走向微服务化的整个过程，以下整理自网易考拉陶杨在近期Apache Dubbo Meetup上的分享，通过该文，您将了解到网易考拉是什么平台？

考拉海购运作模式特点讲解

　　考拉在2015年初上线的时候，线上只有七个工程，商品详情页、购物车下单页等都耦合在中间这个online的工程里面。

　　在上线之初的时候，这种架构还是比较有优势的，因为当时考拉的开发人员也不是很多，把所有的功能都耦合在一个进程里面，利于集中开发、测试和上线，是一种比较高效和节省成本的方式。

　　但是随着业务的不断发展，包括需求的逐步增多，开发团队的不断扩容，这时候，单体架构的一些劣势就逐渐的暴露出来了，例如开发效率低：功能之间的相互耦合，不同需求的不同分支也经常会修改同一块代码，导致合代码的过程非常痛苦，而且经常会出问题。

　　再例如上线成本高：几乎所有的发布需求都会涉及到这些应用的上线，同时不断增长的业务需求，也会使得我们的代码越来越臃肿，造成维护困难、可用性差，功能之间相互耦合，都耦合在一个进程里面，导致一旦某一个业务需求涉及的代码或者资源出现问题，那么就会影响其他的业务。比如说我们曾经在online工程里面，因为优惠券兑换热点的问题，影响了核心的下单服务。

　　这个架构在考拉运行的4到5个月的时间里，从开发到测试再到上线，大家都特别痛苦。所以我们就开始进行了服务化拆分的工作。

　　

　　这个是考拉现在的分布式服务架构。伴随着服务化的拆分，我们的组织架构也进行了很多调整，出现了商品中心、用户中心和订单中心等等。拆分其实是由业务驱动的，通过业务来进行一些横向拆分或者纵向拆分，同时，拆分也会面对一个拆分粒度的问题，比如怎么才算一个服务，或者说服务拆的过细，是不是会导致我们管理成本过高，又或者说是否会带来架构上的新问题。

　　考拉的拆分由粗到细是一个逐步演进的过程。随着服务化的拆分，使得服务架构越来越复杂，随之而来产生了各种各样的公共技术，比如说服务治理、平台配置中心、分布式事务和分布式定时任务等等。

　　考拉的服务化实践

　　微服务框架在服务化中起到了很重要的作用，是服务化改造的基石，经过严格的技术选型流程后，我们选用了Dubbo来作为考拉服务改造的一个重要支柱。Dubbo可以解决服务化过程中服务的定义、服务的注册与发现、服务的调用和路由等问题，此外，Dubbo也具有一些服务治理的功能和服务监控的功能。下面我将介绍考拉基于Dubbo做的一些服务化实践。

　　首先来说一下 熔断。

　　在进行服务化拆分之后，应用中原有的本地调用就会变成远程调用，这样就引入了更多的复杂性。比如说服务A依赖于服务B，这个过程中可能会出现网络抖动、网络异常，或者说服务B变得不可用或者不好用时，也会影响到A的服务性能，甚至可能会使得服务A占满整个线程池，导致这个应用上其它的服务也受影响，从而引发更严重的雪崩效应。

　　因此，服务之间有这样一种依赖关系之后，需要意识到服务的依赖其实是不稳定的。此时，需要通过采取一些服务治理的措施，例如熔断、降级、限流、隔离和超时等，来保障应用不被外部的异常拖垮。Dubbo提供了降级的特性，比如可以通过mock参数来配置一些服务的失败降级或者强制降级，但是Dubbo缺少自动熔断的特性，所以我们在Dubbo上引入了Hystrix。

　　

　　消费者在进行服务调用的时候会经过熔断器，当服务提供者出现异常的时候，比如暂时性的不可用，熔断器就会打开，对消费端进行调用短路，此时，消费端就不会再发起远程调用，而是直接走向降级逻辑。与此同时，消费端会持续的探测服务的可用性，一旦服务恢复，熔断器就会关闭，重新恢复调用。在Dubbo的服务治理平台上，可以对Hystrix上运行的各种动态参数进行动态的配置，包括是否允许自动熔断，是否要强制熔断，熔断的失败率和时间窗口等等。

　　下面再说一下 限流。

　　当用户的请求量，调用超过系统可承受的并发时系统QPS会降低、出现不可用甚至存在宕机的风险。这就需要一个机制来保护我们的系统，当预期并发超过系统可承受的范围时，进行快速失败、直接返回，以保护系统。

　　Dubbo提供了一些基础的限流特性，例如可以通过信号量的配置来限制我们消费者的调用并发，或者限制提供者的执行并发。但是这些是远远不够的，考拉自研了限流框架NFC，并基于Dubbo filter 的形式，实现了对Dubbo的支持，同时也支持对URL等其他资源的限流。通过配置中心动态获取流控规则，对于资源的请求，比如Dubbo调用会经过流控客户端，进行处理并判断是否触发限流，一旦请求超出定义的阈值，就会快速失败。

　　同时，这些限流的结果会上报到监控平台。上图中的页面就是考拉流控平台的一个监控页面，我们在页面上可以对每一个资源(URL、Dubbo接口)进行一个阈值的配置，并对限流进行准实时监控，包括流控比率、限流次数和当前的QPS等。限流框架除了实现基本的并发限流之外，也基于令牌桶和漏桶算法实现了QPS限流，并基于Redis实现了集群级别的限流。这些措施保障系统在高流量的情况下不会被打垮。

　　考拉在监控服务方面的改造

　　在服务化的过程中，系统变得越来越复杂，服务数量变得越来越多，此时需要引入更多维度的监控功能，帮助快速的去定位并解决系统中的各类问题。监控主要分为这四个方面，日志、Metrics、Trace和HealthCheck。