Leader-us，本名为吴治辉，拥有超过15年的软件研发经验，精通Java编程，专注于电信软件和云计算方面的软件研发，参与过众多与分布式、云计算相关的大型项目的架构设计和编程，具备丰富的大型项目架构设计经验，是业界少有的具备很强编程能力的S级资深架构师，目前就职于惠普。此外，他还是国内知名开源分布式数据库中间件MyCat的发起人。目前MyCat项目已经有超过15名活跃志愿者在参与和推进，其社区QQ群人数超过2000人，是当下热门的移动互联网和云计算项目必备基础中间件之一。

　　由于具备很强的技术功底和丰富的项目开发经验，并且文笔幽默，他的文章具备很强的实践性，可直接用于解决项目开发中的实际问题，而且阅读起来轻松有趣，让人有耳目一新的感觉，比如网上流传很广的一篇文章《分布式数据库MyCat之前世今生》，就是他的典型文笔风格。

　　★在App产品中，有一个非常重要的技术难点，那就是消息推送。首先你得考虑用短连接还是长连接，还得考虑手机耗电，最重要的是服务端是否能支撑几万到上百万的移动客户端，服务器的硬件成本也是你必须面对的问题。如果你的技术很牛，则可以使用Netty、NIO来开发服务端，但是在这方面若没有一定的时间及网络通信技术的浸润，稳定性会是一个大问题，时间对创业团队来说，更耽搁不起。为此，我建议你读一读Leader-us所著的《ZeroC Ice指南》，它可以帮你解决问题，让你的移动互联网创业进程加速。Leader-us是MyCat项目的发起人，是业界少有的具备很强Coding能力的S级资深架构师，其在代码和架构方面的功力让我们惊叹，还是那句话：相信Leader，没错的！
　　——金域集团架构师，瑞金泰基金公司投资人&首席架构师  冰风影

　　★作为一线技术人员，老吴让我点评一下他的著作，出于技术人员的务实本性，一开始我是拒绝的，要求他发几章过来阅读，当时还带着看“宝典”“深入浅出”等书的心态。然后，Duang！我沉默了！从他的书中，我看到了老吴作为技术人员的务实性，从云技术到分布式架构，以及目前主流开源技术框架的介绍与使用，到作为架构师所应具备的能力与眼界，每一章都是干货。如果你有幸拿到本书，请认真阅读，相信你的收获会比我的更多！
　　——开源项目MyCat-Web 作者，国药物流IT部技术经理  黄鑫

　　★老吴是我在软件研发方面的恩师，对系统架构和分布式有着极深的理解。从老吴身上学习到的东西，无论是之前在阿里巴巴工作期间，还是如今在互联网领域创业期间，一直让我受益匪浅。本书深入浅出，非常值得一读。
　　——80后互联网创业精英，上海微悉  董小国

　　★Ice是优秀的通信中间件，是用于建立高性能、高伸缩性通信基础设施的平台框架。本书是业内本关于Ice的纸质书籍，作者深入浅出地展示了如何基于Ice进行通信端的架构设计与开发。无论你有志于移动端的开发，还是想成为互联网架构师，本书都是很好的选择。
　　——80后架构师，上海嘉道  meteor

　　★伴随着“互联网+”的火爆热度，企业对IT的需求更加强烈，打造一套属于企业自己的高性能、高可用、可扩展的系统更是迫在眉睫。Leader-us所著的《ZeroC Ice指南》以项目案例驱动的方式，将分布式系统平台建设中遇到的种种问题进行了抽丝破茧式地解析与精讲，所谓一书在手，加薪无忧！
　　——炼数成金总监  黄围围

　　★Leader-us，是我曾经的同事，也是我的师傅，一名摩羯座IT男，很有才华，对技术很执着；任何事情，或者他不做，如果做了，就会尽力做到。作为一名半路出家的程序员，老吴在我技术成长的道路上给予我非常大的帮助和宝贵的建议，他非常乐于帮助他人提升技能，更喜欢技术交流。本书内容由浅入深、通俗易懂，非常适合技术人员阅读，如果你想向架构师乃至更高的技术方向发展，就更不能错过它。
　　——上海浙大网新易得研发总监  孙娟

　　★Leader-us对IT行业总是充满热情，他是技术的先行军，也是众多软件开发人员的良师益友。他的文和书，总是专业而又幽默，再晦涩难懂的技术也会在他的妙笔下开出花儿，本书也不例外，精彩无限，值得你拥有！
　　—— 80后IT美女，新锐派IT讲师，IT技术书籍原创作者  阿蜜果

　　2.1   Ice平台介绍
　　Ice师出名门，是由前CORBA专家Marc Laukien、Michi Henning及Matthew Newhook等人开发的新一代的面向对象的分布式系统中间件。因为是业界知名的分布式标准的缔造者们所打造的新一代分布式中间件，所以Ice既继承了CORBA的一些血统，也精简了CORBA的很多过于复杂而又缺乏实用性的功能，使得平台变得简捷而又高效，并且在IT，也上第一次真正实现了CORBA当初的宏大目标：语言和平台中立、高效通信，却没有CORBA的复杂和各种兼容性问题（这也是最终导致CORBA死亡的两个最重要因素）。除此之外，Ice又增加了一些创新性的特征：比如采用了统一的通信协议和底层框架，增加了UDP传输调用的支持，同时支持异步调用和SSL安全调用，并且随着IT技术的变化和发展，Ice在不断地推陈出新，每年都有新版本问世，从诞生到当下，十几年的历史，其王者地位无人撼动。
　　Ice采用了与CORBA同样的原理，通过与具体编程语言无关的中立语言Slice（Specification Language for Ice）来描述服务的接口，从而达到对象接口与其实现相分离的目的。Slice是建立在客户与服务器之间的合约，用以描述应用所使用的类型和对象接口。它独立于实现语言，所以客户采用的语言与编写服务器所用的语言没有任何关系。
　　为了做到在各个语言和平台上都能100%正确实现Slice的语义和Ice平台的承诺功能，ZeroC公司花费了大量人力，逐个实现了各个主流编程语言与操作系统上的Ice运行库及运行环境。目前Ice平台支持的语言有C++、NET、Java、Python、Objective-C、Ruby、PHP、JavaScript等，而Ice的运行库和运行环境则涵盖了PC平台和移动设备，PC平台支持Windows和主流的Linux发行版，移动设备目前支持Windows Mobile、Android及iOS。此外，由于其杰出的高性能和多语言多平台支持，Ice经常被各公司用在一些关键项目的开发中，其官网给出的客户名单有Wave Fax、PC Soft、Skype、宝钢、宝信软件等超过30家公司。
　　Ice关注于一个技术核心问题——RPC通信，经历了十几年的发展，在很多细节方面都有一些值得称道的做法，下面是其中一些关键特性。
　　◎ 支持多语言之间的RPC互通。与众多平台不同，在它的服务端也可以用几种语言开发，比如C、.NET、JAVA、Python等，不同语言开发的服务端与客户端可以完全互通，对于支持多语言的服务来说，是很难得的一个特性，省去了大量的开发成本和开发周期。
　　◎ 高性能RPC调用。这点是业界公认的，一些大型联网游戏及Skype等对实时性要求很高的系统都采用了Ice平台，这足以说明这一点。笔者也曾做过简单对比，也验证了其高性能，而且在不同语言的客户端调用时，其性能仍然很好。
　　◎ 支持传统的RPC调用、异步调用、One-Way调用、批量发起请求，支持TCP通信、UDP通信，适用于不同的业务场景。
　　◎ 支持安全通信，Ice框架里提供了支持业界标准的SSL安全加密的可拔插插件。并且多种编程语言都支持该特性。
　　◎ 多平台支持。包括X86系统、ARM、移动设备等。
　　◎ 提供了强大的IceGrid。支持注册表主从备份，无单点故障，服务按需启动，随时扩容和迁移，完备的负载均衡机制无须客户端重启，自动感应服务位置的变化。
　　◎ 不断更新，与时俱进。对近些年流行的JavaScript语言及新的移动平台的支持都能及时跟上。
　　这里，笔者仅就多语言开发支持这一特性来分析Ice平台所能带给你的额外价值，当你采用Ice框架开发一个服务后所能直接变现的承诺，在图2.1中可以得到完美诠释。
　　对于一个规模较大的平台来说，开发一个服务并不很难，但如何让多种语言都能很一致地调用你的服务并联调通过，则很不容易，即使对于SOAP这种看似很标准的接口来说，依然存在很多编程语言和SOAP框架的版本兼容性不好的问题。而HTTP Rest的接口在联调时还会碰到各种参数问题。从经验来看，除非把一个现成的编译好的客户端代码发给对方，否则会开发一次，到处联调，形成平台开发的梦魇。
　　下面我们来看看Ice平台的组成，Ice平台从功能可以划分为以下几部分。
　　◎ Slice工具。将Slice语言定义的服务接口编译成各种具体语言的实现代码，属于开发环境的一部分。
　　◎ Ice容器和命令。包括IceGrid、Ice Registry、Ice Node、Ice Admin、IcePatch等命令，用于启动、管理IceGrid，需要在运行Ice服务的机器上选择性地部署其中的某一个或几个组件。
　　◎ Ice运行库。为一组API库，不同的语言有不同的实现，如Java对应JAR文件，C语言对应.so文件（在Windows下对应.dll文件），这些运行库需要被Ice服务端程序和客户端程序所调用，以实现Ice内部的底层通信。
　　下面我们看看采用Ice平台开发一个具体项目时所要遵循的一般流程，如图2.2所示。
　　这个开发流程示意图告诉我们，怎样从零开始开展Ice跨平台的项目开发活动，简单地说，就是首先用Slice语言定义中立的服务接口文件，然后采用相应语言的命令行编译生成对应的程序骨架源文件，最后实现服务端业务代码开发，部署服务，然后客户端利用Ice提供的运行期客户端Library（JAR文件）实现远程服务方法调用，详细流程如下。
　　◎ 分析和设计系统的服务：采用面向服务架构或者“微服务”的设计理念进行系统分析和设计，确定系统中的“服务”单元、每个服务的接口及服务之间的依赖关系。
　　◎ 服务接口定义：采用Ice Slice语言对服务接口进行定义，并用Slice工具编译成你所熟悉的开发语言（本书以Java为例）的实现代码，这些实现代码包括服务端和客户端骨架代码，可以认为是项目中的“公共”包。
　　◎ 服务端业务逻辑实现：在Slice生成的服务端代码上进行业务逻辑代码的编写，在这个过程中除了在服务之间相互调用时用到Ice的一些API外，在绝大多数情况下，不会用到Ice的代码。
　　◎ 编写IceGrid的服务描述文档：xxxgrid.xml，此文档类似于J2EE的web.xml或 EJB的服务描述文件，定义了每个服务的访问地址（Endpoint）、部署的节点（Ice Node）、负载均衡策略（replica-group）等关键信息。
　　◎ 打包代码并部署到各个Ice Node上，启动IceGrid，借助Ice工具发布xxxgrid.xml，服务端工作至此基本完成。很重要的一点是，借助Ice平台提供的工具，你可以很方便地将xxxgrid.xml中的服务重新规划和部署到新的节点上，而客户端无须重启和改变任何代码。
　　◎ 编写客户端软件，访问部署好的服务，并有针对性地做性能测试和调优。
　　初步了解了Ice的特性、组成部分及开发流程之后，让我们休息一会，因为接下来需要学习和理解Ice平台的几个重要术语和概念，这个是需要动脑筋的，随便看看绝对无法过关。
　　2.2  Ice的概念和原理
　　2.2.1  Ice Object
　　任何系统都会使用一些专有名词来阐明其原理和实现机制，最终，往往几个名词就概括了其背后庞大复杂的技术体系，比如现在流行的Hadoop、NoSQL、NewSQL、BigData等。对于一个复杂的系统来说，准确理解和掌握其专有术语非常重要，不仅仅因为在相关的技术文档里大量使用了这些概念和术语，而且因为在编程实践和问题排查过程中，这些概念和术语有助于我们推理、分析问题产生的根源和发现可能的解决方案。
　　作为一个复杂的RPC平台，Ice也创造了很多概念和术语，其中一个名词就是Slice，Slice模仿CORBA的IDL（Interface Definition Language）而来，与IDL相似，Ice采用编程语言中立的Slice这种接口描述语言来定义一个RPC服务接口，然后提供了指向具体编程语言的“翻译工具”——slice2XXX，该工具将Slice文件编译成相应语言的源码，这些源码中包括了客户端运行时期的Stub代码，以及服务器端的Skeleton框架代码。要理解这一切背后的秘密，则需要从Ice最根本的概念——Ice Object说起。
　　Ice Object具有以下特征。
　　◎ 拥有一个对象标识符Object Identity来区别于其他类型对象，Ice的对象模型中要求对象标识符是全局唯一的，即没有任何对象的标识符相同。
　　◎ 一个Ice Object是一个可以对客户端请求进行应答的对象，这个对象可以位于“本地进程的地址空间”，也可以位于“远程地址空间”。
　　◎ 一个Ice Object拥有一个或多个接口，其中一个接口是其主要接口，是此对象区别于其他对象的主要特征，其余接口则被称为Facet。
　　一个Ice Object在服务端具体化为一个Servant实例，即我们用某种具体编程语言实现的一个Slice接口并新建的某个对象就是一个Servant。而将Ice Object与Servant进行关联的“桥”则是我们接下来要理解的概念—— Object Adapter，它是Ice运行时框架与用户应用程序代码之间的边界点，Object Adapter具有以下功能。
　　◎ 提供一个或多个通信端点（Transport Endpoint），客户端通过这些端点中的某个端点连接到一个具体的Ice Object对象，一个Endpoint由服务端所使用的通信协议、IP地址、端口等信息所组成，如default -h 192.168.0.1 -p 1000，表明是采用默认的协议（TCP），绑定在192.168.0.1的端口1000上的一个通信端口。
　　◎ 绑定一个或多个Servant，每个Servant与一个Ice Object映射，将客户端针对某个Ice Object的请求派发映射到对应的Servant上，并完成整个请求流程的处理过程，包括底层通信。
　　◎ 协助生命周期管理，消除Ice Object与Servant在启动和销毁的过程中所可能存在的竞争问题。
　　从上面的Object Adapter的功能来看，很多时候我们可以把Object Adapter与在它之上绑定的Ice Object等价，因为Object Adapter是Ice Object的“宿主”，不但提供了Ice Object的访问地址（Endpoint），而且负责完成请求处理转发的流程。因此，你会看到很多时候有这样的写法：SimplePrinter@PrinterAdapter。
　　2.2.2  Ice Proxy
　　接下来让我们看看Ice Object在客户端的代表——Proxy，简单地说，Proxy是客户端用来访问远程某个Ice Object的本地“代理”，Proxy存在于客户端的进程地址空间中，“代表”一个远程对象，当客户端调用远程对象的某个方法时，Ice运行时期的客户端代码库（Ice Runtime）会完成如下具体工作。
　　◎ 定位远程对象Ice Object。
　　◎ 如果Ice Object所在的Server处于关闭状态，则自动激活此Server，并激活远程对象。
　　◎ 将方法的入参（传入到远程对象的参数）通过Socket传输到远程对象。
　　◎ 等待调用完成。
　　◎ 将方法的出参（返回给调用者的参数）返回给客户端，若发生异常则抛出调用异常。
　　作为远程Ice Object的本地“代理”，Proxy还持有如下重要信息。
　　◎ 远程Server的地址信息，用来初始化通信。
　　◎ 用来定位Ice Object的对象标识符：object identity。
　　◎ 可选的Facet标识符，用来确定引用Ice Object的哪个接口。
　　◎ 一个具体的Proxy可以用一个包括Endpoint信息的字符串描述，比如SimplePrinter：default -p 10000，表示在远端的TCP端口10000上绑定的一个SimplePrinter对象的Proxy，代码中我们可以用这样的特定格式的字符串，来构造一个Proxy对象。
　　Endpoint通常可以理解为一个访问地址，在WebService中也有这个词：“当我们Host一个Web Service时，我们必须为其定义一个或多个Endpoint，然后Service通过这个定义的Endpoint监听来自Client端的请求”。在Ice中，Endpoint有UDP或TCP两种，但基本上很少用UDP，因为在现在的高速网络带宽采用TCP长连接的情况下，UDP基本上没有什么优势了。
　　Proxy有Direct Proxy与Indirect Proxy两种，前者直接绑定某个远端Object的访问地址，如SimplePrinter：default -p 10000；后者则不绑定远程Object的某个具体的通信地址，而且有两种写法，其中第一种写法是直接引用远程对象的标识符，如SimplePrinter，这种对象需要被定义为Well Know Object，第二种写法是SimplePrinter@PrinterAdapter，即访问绑定到某个ObjectAdapter之上的某个对象，此时不需要Ice Object为Well know Object。对Indirect Proxy来说，由于没有远程对象的具体地址信息，因此，需要借助寻址服务——Location Service来获取对应Ice Object的通信地址。
　　……