在这难得的几天闲暇之际，不经意间，看了看之前的博客，才恍然发现，自己都已经毕业4年多了。看着毕业之际写的那篇《我的2011》，再回顾下这几年自己的技术路程，感慨良多。所以，一时意起，又敲起了键盘，来回顾下这几年自己走过的路，给不断前行的自己，再留下一个脚印......

在U8SDK整套框架总体架构那篇文章，我们就给出了服务器端的解决方案，为此，我们加入了一个U8Server,来作为U8SDK整套框架的服务器端的统一用户认证中心和支付中心。那么，为了方便，我们这里再来引用一下登陆认证的流程图：回顾下我们之前的分析，U8Server作为统一的登陆认证中心，针对的是多款游戏，那么每款游戏在接入SDK之前，就需要向U8Server申请一个

整套u8sdk的核心思想，就是让我们的SDK接入成本，能够控制在1，而不是N。啥意思呢？就是，我开发第一款游戏的时候，我接了这些SDK，当我开发第二款，第三款游戏的时候，这套SDK可以尽可能的复用，而不是每开发一款游戏，又从头去接各个渠道sdk。所有的游戏都能够使用同一套SDK接入框架，来快速完成SDK的接入工作。那么，在U8SDK里，我们怎么做到呢？请看我们总体的思路：

今天发现早年在大象笔记中写的一篇笔记，之前放在ijavaboy上的，现在它已经访问不了了。前几天又有同事在讨论这个问题。这里拿来分享一下。在web应用开发或者游戏服务器开发的过程中，我们时时刻刻都在使用热部署。热部署的目的很简单，就是为了节省应用开发和发布的时间。比如，我们在使用Tomcat或者Jboss等应用服务器开发应用时，我们经常会开启热部署功能。热部署，简单点来说，就是我们将打

U8Server支持分布式部署之后， 我们还有一个问题需要解决， 那就是分布式环境下，唯一订单号生成问题。 之前U8Server的订单号生成规则是 32位时间戳+32位序号，最终生成一个64位的long类型的订单号。之前也考虑过，使用UUID等方式， 但是综合考虑下来， 我们决定还是让订单号使用数字类型（好排序），同时让订单号逐渐递增，并具有一定的自解释语义（这里主要指的是订单的产生时间）支持分布式