(服务化架构的演进与实践.docVIP

【编者按】在构建一个高性能Java版的服务框架时，哪些技术是最核心的要素？服务化过程中有哪些最容易出现的问题，该如何解决？服务架构的演进方向又是什么样的？华为分布式服务框架首席设计师李林锋为大家一一解答了这些问题。 以下是他的演讲实录： 今天我的演讲内容分为三个方面，首先看一下传统应用开发面临的挑战。我2008年到华为至今，我个人的体会和整个华为的Java的发展，包括很多互联网的公司其实都在按照这样的一个方向。第二点是服务化的实践。最后一点是服务架构的演进分析。 传统应用开发面临的挑战 挑战一：研发成本高 2008年我来北京参与当时华为的一个TOP3的项目，甲方是中国移动。那时公司也刚做Java类的软件，还没有服务框架和中间件，唯一有的是外部的框架。我们要做的是后台消息类系统，前端界面非常少。分工和协同完全靠人工来进行，并且没有考虑交互，当时面临着代码重复率高、需求变更困难和无法满足新业务快速上线和敏捷交付这些难题。 挑战二：运维效率低 对于运维感受比较深的是07年我在东软做一个ERP的系统。主要问题包括： 测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。 可伸缩性差：水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。 可靠性差：某个应用BUG，例如死循环、OOM等，会导致整个进程宕机，影响其它合设的应用。 代码维护成本高：本地代码在不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原来的开发者才理解接口调用关系和功能需求，新加入人员或者团队其它人员很难理解和维护这些代码。 依赖关系无法有效管理：服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 解决对策 要解决上面的问题，我们采用的主要的第一个措施是拆分，包括水平拆分和垂直拆分。拆完以后我们会发现我们按业务的领域形成各种各样的一个独立的集群的中心，一个资源的池子。我们在开发应用的时候都会发现无论需求怎么去变化，其实它容易发生变化就是20%左右的功能，其实最终我们要把变化给隔离出来，控制这个变化。做法就是要抽取和识别我们的核心，我们的公共的要沉淀到下层形成一个公共的独立能力层，然后逐渐形成稳定的一个服务能力中心再下沉。前端包括中间编排层的变化给它抽象出来，做一个消费者去做。这样前后端分离以后，我们就可以有效的去管理。能管控住变化以后的需求变更，包括测试和整个的成本其实都是可以得到一个有效的控制。 服务化实践 服务的订阅发布 图1 如图1所示，我们无论是用过MQ或者中间件有一个流行的做法，第一个就是说服务或者位置的一个透明，但随着规模的扩大，人工应用管理这些地址的时候成本会非常高。第二点是很多东西现在都上到云，云的很大特点是它的弹性跟伸缩。弹性跟伸缩意味着它随着有可能会跳入，但是它的IP都是动态的，如果我们没有一套动态发现机制的话，软件的敏捷性会非常差。 现在一种非常流行的做法是服务提供者会把它的服务注册到注册中心，消费者会去订阅拉取这些消息，然后在本地缓存一个提供者的信息。这样每一次交互的时候，只查本地内存就可以了，不需要强依赖这个注册中心，实际上对服务中心依赖就是一个弱依赖。 当然其他做法也有很多，管理的服务节点数在万级以内用ZK比较成熟，规模再大一点时延和性能包括可靠性会有一些问题，这时可以考虑一些其他的技术手段。 第二点其实就是服务的发布和消费，以前我们用中间件或者ESB，包括在用Netty的时候，都会担心版本的兼容性。版本的变化可能使其实整个目录都发生重构，切到独立的IO点的话，这个变化是很麻烦的，所有的东西都需要过，不要说底层的限制模型和其他的一些用法的修改，这个就得用很多时间。 零侵入 所以在我们实际设计过程中，很希望这个服务框架或者服务化对上层应用的侵入尽可能小，但百分百零侵入是做不到的。通过配置化的方式——即Spring的方式，通过配置和扩展、消费、发布，其实配置本身是一个侵入，是代码的一部分。但是这个有的好处是我们改一个代表总比去编译它强。就是说我们尽量少的开放服务框架的API给上层，而开放的都是一些特性和配置化的方式，或者是用注解也可以。 这样的话，未来我们的服务框架无论是底层做什么样的整合和重构，其实我们都不用再担心。当然，这个也是比较流行的做法，有一些做的比较好的，可能是硬编码、基于配置和注解都支持，像亚马逊AWS做的只支持注解。 容错和路由 首先讲路由。在同一个机房以内的路由会提各种各样的策略。比如说按照服务的负载做路由或做自定义的路由。其他的跨数据中心和跨地域的，要考虑容灾和跨机房的路由。我们的策略是常用的路由肯定要提供的，但只有基础路由肯定是不够的，最终要把路由策略扩展出去。当然这个策略有很多种，比如说有一些做法是把路