应急预案，顾名思义就是在发生突发安全事件时，能够起到应急处理的解决方案。还记得我刚参加工作时，领导就跟我说过这样一句话，平时的运维工作做得再好，也抵不上在发生突发事件情况下的应急处理能力，我们有必要将应急演练作为一个员工的考核指标。这句话虽然是半开玩笑的一句话，却是一位多年运维工作者的经验结晶。
 

 
可能有人觉得这句话似乎夸大其词，想必做过运维的人都知道，尤其是一线处理岗，每天面对的都是一些简单的、重复的、看似毫无技术含量的工作，所以就有人提出来要提高数据中心建设的标准化、可视化、自动化和智能化的运维水准，这的确可以解放运维工作的生产力。可谁曾想过，当运维过程中发生一些突发事件时，尤其需要一些手工操作时，这时候的自动化工具，或是智能机器人等它们能够解决这些没有事先按既定程序指令去应急吗？亦或是要求他们对故障原因、事件影响范围以及可能引发的二次事故进行分析吗？答案显然是否定的，我举一个运维过程中可能不太重视的一个环节。
 
大家都知道UPS系统在数据中心供配电系统的重要性，除了安排专人对其运行工况进行维护，也有很完善的监控系统对其运行工况实时监控，还要求服务商每月对其进行健康检查，发现一些潜在的威胁，但一些小的部件可能在我们日常运维过程被忽视。为了防止UPS系统过高温运行，影响其使用寿命，其内部会安装温度传感器实时监测本机运行。这个温度传感器是UPS系统中很小的一个部件，小的很容易被忽视，我所就职的数据中心就曾发生过类似的情况。当天值班人员在监控中发现了该台UPS系统的高温报警，误以为是配电机房工作环境温度过高，就现场对本机做了消音处理，开启了配电间的排风系统（当时已过了立夏，室外温度比较高）。可过了一段时间，UPS系统持续报高温预警，本地上却无其他异常，转而远程求助服务商，服务商给出的建议是变更期间更换温度传感器（其实，服务商不总是靠谱的，他们不曾做过运维，也就不能够深刻体会到安全生产事故给数据中心造成的影响）。机组运行一段时间后，监控系统报警升级，电池电压过低。这个时候会不会觉得很奇怪，怎么又跟电池有关系了。由于服务商推脱，故障未及时得到解决，机组持续“高温”运行，UPS本地启动了自保护功能，断开了整流器转电池旁路供电，等温度降下来后又转UPS主回路工作，这两种工况反复，引发了次生故障，将故障影响扩大化。试想一下，如果此时出现市电波动，又或是值班人员粗心不在关注此类报警，下游负载就会出现失电的威胁，从小的方面说，电池的放电次数有限，且深度放电会严重影响其使用寿命（电池成本昂贵），从大的方面说，这也可能影响数据中心的正常运营，不仅给企业带来业务上的损失，也会给企业名誉造成影响。相反，如果此类情况被反复演练过，运维值班人员就会很清楚知道该类故障的解决方案，也会很清楚地了解该类故障可能引发的次生威胁，所以此类故障在应急预案的前提下，可以有条不紊的得到完美解决。
 
另外，应急预案中“预”字，即预习、演练之意。它要求运维人员提前熟练掌握应急流程，定期高效地组织演练培训，做好应急故障的预防预测，以及及时更新应急预案的演练内容（数据中心在运营过程，会逐渐优化和改造原有系统架构），做到对突发事件的稳妥处理，成竹在胸。
 

 
资料免费送（点击链接下载）
 史上最全，数据中心机房标准及规范汇总（下载）
 

 
数据中心运维管理 | 资料汇总（2017.7.2版本）                                                    

 
加入运维管理VIP群（点击链接查看）
 
《数据中心运维管理》VIP技术交流群会员招募说明
 
加入学习群扫描以下二维码或者添加微信：
 
wang2017bj
 
 

作为一个有追求的技术开发人员，总是希望能够做出好的技术。
 
那么对于游戏研发领域，什么样的技术才是好的技术呢，技术对于游戏研发的重要性如何呢。在从业若干年之后，我个人的总结是：好的技术创造好的游戏体验，提高开发效率。
 
 
 
首先，好的技术可以创造出好的游戏体验，这些体验包括：
 
1.游戏画面带来的视觉体验
 
这一点最为直观。逼真，或者酷炫的画面可以给予玩家强烈的视觉感官刺激。例如当年以画面作为最大卖点的《孤岛危机》。有时游戏画面并不是越真实越好。有些产品为了特殊的艺术表现，会追求“风格化”的画风，比如FPS游戏《无主之地》。这类风格化的画面有时可能会比基于真实物理世界的画面更加难于实现。
 
2 某些游戏类型的核心体验
 
有些游戏类型各自有一些必须要做好的核心特性。比如FPS游戏的画面必须要流畅，这样才能保证瞄准的手感。即保持很高的帧率（一般都要做到垂直同步的帧率），并且要维持帧率稳定。MMO游戏需要在同一个场景中支持尽可能多的玩家同时游戏和交互。模拟类游戏要针对模拟的对象建立起复杂的模型，模型既要能反映现实，又要容易理解和实现。而像炫舞这类音乐游戏则需要保证音乐的节拍，画面，和用户的输入能够精确的匹配，换句话说就是让玩家感觉能够很准的打到拍子上。
 
这些关键点对于这些游戏至关重要，是游戏性的前提。同时也具有一定的壁垒。
 
3 一些游戏性无关的体验
 
还有一些技术指标，和游戏性无关，但是会很大程度上影响玩家的游戏体验。例如游戏启动和切换场景时的loading速度。通过网络进行更新和下载时的速度。点击按钮时的UI响应速度等。
 
不要小看这些细节，如果处理不好，产品的品质是会大打折扣的。只要给予足够的重视，很多问题是可以比较容易的解决的。比如压缩资源体积，合理规划下载包的大小，以及合理的cache管理等等。
 
4. 保证在不同硬件平台上的体验
 
PC平台的机器硬件千差万别。PC上运行的游戏需要有很好的伸缩性，能够在各种不同配置的机器上都获得比较好的体验。这需要对各种硬件平台特性非常熟悉，并且对游戏占用系统资源整体状况有深入的理解和把控。移动平台上，特别是Android平台的状况与PC很类似。
 
 
 
其次，好的技术提高开发效率，降低开发成本。
 
游戏开发毕竟是商业活动，降低成本，追求利润是天经地义的。
 
而好的技术选型，完善的工具集可以极大的提高效率，降低成本。这一点做得好不好能够反映出游戏研发团队的专业程度。
 
游戏开发是极其复杂的工程实践。而游戏开发的目标：“好玩”，“好看”都是非常感性的，无法用明确的标准来衡量。因此，对于一个游戏产品，不可能从一开始就明确最终想要的效果。通常是需要先做出一个粗糙简陋的版本，然后不断地改良和优化，对每一个细节反复的打磨。这是一个非常耗时耗力的过程，伴随着大量的重复性劳动。这时，趁手的工具就显得非常重要了。好的技术团队会非常重视工具的开发。重视工具的集成度和易用性。各种工具应该形成链条，将整个开发过程串联起来，尽最大可能释放生产力，用更低的成本做出更好的效果。
 
当然，开发工具本身也是有成本的，一次性的工作不需要工具。对于重复性的或者复杂度高的工作，对于工具的投入绝对是值得的。此外，工具应该尽可能通用，可以积累下来应用到后续的项目中去。毕竟一个团队不可能只做一个项目。
 
另一方面，合适的技术选型会极大的降低开发成本和技术风险。例如一些卡牌类手游的服务器使用了基于web服务器的架构，游戏逻辑使用PHP开发。其开发效率比传统的c++开发的服务器高数倍甚至数十倍，从而节约了大量的人力成本和时间成本。
 
 
 
最后，好的技术需要跟产品紧密结合，并且敢于创新。
 
举两个例子。《天涯明月刀》中的帮派战会出现很多玩家在一个密集的区域内战斗。这对游戏的性能优化造成了很大的挑战。但是天刀团队聪明的设计了一个“校服”系统，帮派成员穿一样的衣服可以获得数值加成。大部分的帮派成员都会穿校服。而相同的模型批量绘制是有高效的技术方案的。这是一个经典的技术方案与产品设计完美结合的例子。
 
在《炫舞时代》研发的初期，我们的引擎还是使用的传统的前向渲染。前向渲染有一个弱点是不能支持很多的动态光源。而《炫舞时代》的主要游戏场景是舞台，如果渲染系统能够支持很多的动态光源，则可以极大地提升游戏画面的感染力。当时实时渲染领域已经有了这样的技术，就是延迟渲染。但市面上还没什么产品使用这项技术。这时我们的技术团队做出的大胆的尝试，率先在国内自研游戏产品中使用的这项技术，最终的效果非常好。
 
 
 
总而言之，好的技术对于游戏研发团队非常重要。特别是当游戏产品进入到了“精品”和“大作”的时代，更是如此。需要承认的是，国内的游戏研发技术与欧美，日本的顶尖团队相比还有较大的差距。要全面赶上还有很长的路要走。但好的技术来自于经年累月的积累和总结，需要付出大量的心血。而这源源不断的动力需要来自于对技术的热爱和对游戏的热爱。与所有热爱这份事业的朋友共勉！

    对于软件的版本控制与管理，一直很重视，这种重视主要体现在对于多人的合作的项目上，但是对于小到一个甚至二个人的项目，觉得没有什么必要，结果昨天的一次小意外，让人有了劫后余生的感觉，看来以后只要有项目，不论多少开发人员，那怕只有一个，也要做好版本的管理。
 
　事情是这样的，二个人合作的一个Java方面的项目，前期用SVN进行版本控制，一直用得很好，到了后期，由于另一名开发人员在忙于别的事情，这个项目就我一人在做，这个状态持续了近一个月，慢慢就懒得向SVN服务器上提交代码了。
 
　昨晚用Eclipse玩一个新东西，在玩的时候，因为误操作一不小心将这个项目给删了，并且删得还比较彻底，这下傻眼了，因为这个项目下周就要交了，自己在测的时候也测的差不多了，小项目没有用测试人员帮忙。
 
　心情一下便沉重起来，静一静后，开始想解决办法：
 
　1.　看用Eclipse提供的功能能不能直接恢复
 
　2.　下硬盘数据恢复软件，尝试恢复
 
　3.　实在不行请专业恢复人员进行恢复。
 
　4.　评估损失，重新写代码
 
　打定好这三个方案，开始按步就班的执行，方案一不行，方案二下了两个软件
 
　一个叫smartundelete.rar，另一个叫datarecovery。分别进行了各种功能上的恢复，竞然发现都不行，不过确找回了从前一些删除的文件。这也算是意外收获吧。
 
　近三个小时的折腾，结论是方案一，方案二失败，方案三估计要等到周一才能实施，因为这是周六，咬咬牙，开始提前执行方案四，评估了一下损失，发现损失比较惨重，基本上核心的代码都没有向SVN传过。
 
    只好无奈了准备重写了，当时也在安慰自己，正好趁重写修改几处设计不合理的地方，也算是有得有失。
 
　不过正当准备用Eclipse重写时，发现有个历史恢复功能，尝试点了一下，没想到恢复了几个Class文件，又点了第二次，恢复了一些.java文件。呵呵，对classf进行了反编译。又重新整合了能收集到的代码。
 
　很luck，近95％的主要功能恢复了。　
 
　重写了大概300多条代码，一切Ok了。
 
　然后做的第一件事，提交到SVN。
 
 

服务拆分的前提
 
说到微服务，服务拆分是绕不过去的话题，但是微服务不是说拆就能拆的，有很多的前提条件，需要完成前面几节所论述的部分。
  
 
 
 
首先要有一个持续集成的平台，使得服务在拆分的过程中，功能的一致性，这种一致性不能通过人的经验来，而需要经过大量的回归测试集，并且持续的拆分，持续的演进，持续的集成，从而保证系统时刻处于可以验证交付的状态，而非闭门拆分一段时间，最终谁也不知道功能最终究竟有没有bug，因而需要另外一个月的时间专门修改bug。

其次在接入层，API和UI要动静分离，API由API网关统一的管理，这样后端无论如何拆分，可以保证对于前端来讲，统一的入口，而且可以实现拆分过程中的灰度发布，路由分发，流量切分，从而保证拆分的平滑进行。而且拆分后的微服务之间，为了高性能，是不建议每次调用都进行认证鉴权的，而是在API网关上做统一的认证鉴权，一旦进入网关，服务之间的调用就是可信的。

其三对于数据库，需要进行良好的设计，不应该有大量的联合查询，而是将数据库当成一个简单的key-value查询，复杂的联合查询通过应用层，或者通过Elasticsearch进行。如果数据库表之间耦合的非常严重，其实服务拆分是拆不出来的。

其四要做应用的无状态化，只有无状态的应用，才能横向扩展，这样拆分才有意义。
 
 
 
 
服务拆分的时机
 
 
 
满足了服务拆分的前提之后，那先拆哪个模块，后拆哪个模块呢？什么情况下一个模块应该拆分出来呢？

 微服务拆分绝非一个大跃进运动，由高层发起，把一个应用拆分的七零八落的，最终大大增加运维成本，但是并不会带来收益。

微服务拆分的过程，应该是一个由痛点驱动的，是业务真正遇到了快速迭代和高并发的问题，如果不拆分，将对于业务的发展带来影响，只有这个时候，微服务的拆分是有确定收益的，增加的运维成本才是值得的。
  
 
微服务解决的问题之一，就是快速迭代。
 


 互联网产品的特点就是迭代速度快，一般一年半就能决出胜负，第一一统天下，第二被第一收购，其他死翘翘。所以快速上线，快速迭代，就是生命线，而且一旦成功就是百亿身家，所以无论付出多大运维成本，使用微服务架构都是值得的。

 这也就是为什么大部分使用微服务架构的都是互联网企业，因为对于这些企业来讲收益明显。而对于很多传统的应用，半年更新一次，企业运营相对平稳，IT系统的好坏对于业务没有关键性影响，在他们眼中，微服务化改造带来的效果，还不如开发多加几次班。
 
微服务拆分时机一：提交代码频繁出现大量冲突
 
微服务对于快速迭代的效果，首先是开发独立，如果是一单体应用，几百人开发一个模块，如果使用Git做代码管理，则经常会遇到的事情就是代码提交冲突。

 同样一个模块，你也改，他也改，几百人根本没办法沟通。所以当你想提交一个代码的时候，发现和别人提交的冲突了，于是因为你是后提交的人，你有责任去merge代码，好不容易merge成功了，等再次提交的时候，发现又冲突了，你是不是很恼火。随着团队规模越大，冲突概率越大。

 所以应该拆分成不同的模块，每十个人左右维护一个模块，也即一个工程，首先代码冲突的概率小多了，而且有了冲突，一个小组一吼，基本上问题就解决了。

 每个模块对外提供接口，其他依赖模块可以不用关注具体的实现细节，只需要保证接口正确就可以。
 
微服务拆分时机二：小功能要积累到大版本才能上线，上线开总监级别大会
 
微服务对于快速迭代的效果，首先是上线独立。如果没有拆分微服务，每次上线都是一件很痛苦的事情。当你修改了一个边角的小功能，但是你不敢马上上线，因为你依赖的其他模块才开发了一半，你要等他，等他好了，也不敢马上上线，因为另一个被依赖的模块也开发了一半，当所有的模块都耦合在一起，互相依赖，谁也没办法独立上线，而是需要总监协调各个团队，大家开大会，约定一个时间点，无论大小功能，死活都要这天上线。

 这种模式导致上线的时候，单次上线的需求列表非常长，这样风险比较大，可能小功能的错误会导致大功能的上线不正常，将如此长的功能，需要一点点check，非常小心，这样上线时间长，影响范围大。因而这种的迭代速度快不了，顶多一个月一次就不错了。

 服务拆分后，在接口稳定的情况下，不同的模块可以独立上线。这样上线的次数增多，单次上线的需求列表变小，可以随时回滚，风险变小，时间变短，影响面小，从而迭代速度加快。

 对于接口要升级部分，保证灰度，先做接口新增，而非原接口变更，当注册中心中监控到的调用情况，发现接口已经不用了，再删除。
  
 
微服务解决的问题之二，就是高并发。
 

 互联网一个产品的特点就是在短期内要积累大量的用户，这甚至比营收和利润还重要，如果没有大量的用户基数，融资都会有问题。

 因而对于并发量不大的系统，进行微服务化的驱动力差一些，如果只有不多的用户在线，多线程就能解决问题，最多做好无状态化，前面部署个负载均衡，单体应用部署多份。
 
微服务拆分时机三：横向扩展流程复杂，主要业务和次要业务耦合
 
单体应用无状态化之后，虽然通过部署多份，可以承载一定的并发量，但是资源非常浪费。
 
因为有的业务是需要扩容的，例如下单和支付，有的业务是不需要扩容的，例如注册。如果一起扩容，消耗的资源可能是拆分后的几倍，成本可能多出几个亿。
 
而且由于配置复杂，在同一个工程里面，往往在配置文件中是这样组织的，这一块是这个模块的，下一块是另一个模块的，这样扩容的时候，一些边角的业务，也是需要对配置进行详细审核，否则不敢贸然扩容。
 
微服务拆分时机四：熔断降级全靠if-else
 
在高并发场景下，我们希望一个请求如果不成功，不要占用资源，应该尽快失败，尽快返回，而且希望当一些边角的业务不正常的情况下，主要业务流程不受影响。
 
这就需要熔断策略，也即当A调用B，而B总是不正常的时候，为了让B不要波及到A，可以对B的调用进行熔断，也即A不调用B，而是返回暂时的fallback数据，当B正常的时候，再放开熔断，进行正常的调用。

 有时候为了保证核心业务流程，边角的业务流程，如评论，库存数目等，人工设置为降级的状态，也即默认不调用，将所有的资源用于大促的下单和支付流程。

 如果核心业务流程和边角业务流程在同一个进程中，就需要使用大量的if-else语句，根据下发的配置来判断是否熔断或者降级，这会使得配置异常复杂，难以维护。

 如果核心业务和边角业务分成两个进程，就可以使用标准的熔断降级策略，配置在某种情况下，放弃对另一个进程的调用，可以进行统一的维护。
 
服务拆分的方法
 
好了，当你觉得要将一个程序的某个部分拆分出来的时候，有什么方法可以保障平滑吗？
 
首先要做的，就是原有工程代码的标准化
 
 
 
我们常称为“任何人接手任何一个模块都能看到熟悉的面孔”
 
 

 例如打开一个Java工程，应该有以下的package：
 
 
 
API接口包：所有的接口定义都在这里，对于内部的调用，也要实现接口，这样一旦要拆分出去，对于本地的接口调用，就可以变为远程的接口调用。
访问外部服务包：如果这个进程要访问其他进程，对于外部访问的封装都在这里，对于单元测试来讲，对于这部分的Mock，可以使得不用依赖第三方，就能进行功能测试。对于服务拆分，调用其他的服务，也是在这里。
数据库DTO：如果要访问数据库，在这里定义原子的数据结构。
访问数据库包：访问数据库的逻辑全部在这个包里面。
服务与商务逻辑：这里实现主要的商业逻辑，拆分也是从这里拆分出来。
外部服务：对外提供服务的逻辑在这里，对于接口的提供方，要实现在这里。
 

 另外是测试文件夹，每个类都应该有单元测试，要审核单元测试覆盖率，模块内部应该通过Mock的方法实现集成测试。

 接下来是配置文件夹，配置profile，配置分为几类：
 
 
 
内部配置项（启动后不变，改变需要重启）
集中配置项（配置中心，可动态下发）
外部配置项（外部依赖，和环境相关）
 
独立功能模块 ，规范输入输出，形成服务内部的分离
 
当一个工程的结构非常标准化之后，接下来在原有服务中，先独立功能模块 ，规范输入输出，形成服务内部的分离。在分离出新的进程之前，先分离出新的jar，只要能够分离出新的jar，基本也就实现了松耦合。
 

 新建工程，新启动一个进程，尽早的注册到注册中心
 

 接下来，应该新建工程，新启动一个进程，尽早的注册到注册中心，开始提供服务，这个时候，新的工程中的代码逻辑可以先没有，只是转调用原来的进程接口。

 为什么要越早独立越好呢？哪怕还没实现逻辑先独立呢？因为服务拆分的过程是渐进的，伴随着新功能的开发，新需求的引入，这个时候，对于原来的接口，也会有新的需求进行修改，如果你想把业务逻辑独立出来，独立了一半，新需求来了，改旧的，改新的都不合适，新的还没独立提供服务，旧的如果改了，会造成从旧工程迁移到新工程，边迁移边改变，合并更加困难。如果尽早独立，所有的新需求都进入新的工程，所有调用方更新的时候，都改为调用新的进程，对于老进程的调用会越来越少，最终新进程将老进程全部代理。
 
老工程中的逻辑逐渐迁移到新工程
 

 接下来就可以将老工程中的逻辑逐渐迁移到新工程，由于代码迁移不能保证逻辑的完全正确，因而需要持续集成，灰度发布，微服务框架能够在新老接口之间切换。
 
老工程下线
 

 最终当新工程稳定运行，并且在调用监控中，已经没有对于老工程的调用的时候，就可以将老工程下线了。
 
 
 
服务拆分的规范
 
微服务拆分之后，工程会比较的多，如果没有一定的规范，将会非常混乱，难以维护。

 首先人们经常问的一个问题是，服务拆分之后，原来都在一个进程里面的函数调用，现在变成了A调用B调用C调用D调用E，会不会因为调用链路过长而使得相应变慢呢？
 
服务拆分的规范一：服务拆分最多三层，两次调用
 
服务拆分是为了横向扩展，因而应该横向拆分，而非纵向拆成一串的。也即应该将商品和订单拆分，而非下单的十个步骤拆分，然后一个调用一个。

 纵向的拆分最多三层：
 
 
 
基础服务层：用于屏蔽数据库，缓存层，提供原子的对象查询接口，有这一层，为了数据层做一定改变的时候，例如分库分表，数据库扩容，缓存替换等，对于上层透明，上层仅仅调用这一层的接口，不直接访问数据库和缓存。
组合服务层：这一层调用基础服务层，完成较为复杂的业务逻辑，实现分布式事务也多在这一层
Controller层：接口层，调用组合服务层对外
 
服务拆分的规范二：仅仅单向调用，严禁循环调用
 
微服务拆分后，服务之间的依赖关系复杂，如果循环调用，升级的时候就很头疼，不知道应该先升级哪个，后升级哪个，难以维护。

 因而层次之间的调用规定如下：
 
 
 
基础服务层主要做数据库的操作和一些简单的业务逻辑，不允许调用其他任何服务。
组合服务层，可以调用基础服务层，完成复杂的业务逻辑；可以调用组合服务层，不允许循环调用；不允许调用Controller层服务
Controller层，可以调用组合业务层服务，不允许被其他服务调用
 

如果出现循环调用，例如A调用B，B也调用A，则分成Controller层和组合服务层两层，A调用B的下层，B调用A的下层。
 
也可以使用消息队列，将同步调用，改为异步调用。
 
服务拆分的规范三：将串行调用改为并行调用，或者异步化
 
如果有的组合服务处理流程的确很长，需要调用多个外部服务，应该考虑如何通过消息队列，实现异步化和解耦。

 例如下单之后，要刷新缓存，要通知仓库等，这些都不需要再下单成功的时候就要做完，而是可以发一个消息给消息队列，异步通知其他服务。

 而且使用消息队列的好处是，你只要发送一个消息，无论下游依赖方有一个，还是有十个，都是一条消息搞定，只不过多几个下游监听消息即可。

 对于下单必须同时做完的，例如扣减库存和优惠券等，可以进行并行调用，这样处理时间会大大缩短，不是多次调用的时间之和，而是最长的那个系统调用时间。
 
服务拆分的规范四：接口应该实现幂等
 
 
 
 微服务架构中，幂等是一致性方面的一个重要概念。幂等（Idempotent）是一个数学领域与计算机学的概念，常见于抽象代数中。而在编程中，一个幂等操作的特点是指其任意多次执行所产生的影响均与一次执行的影响相同。
 
 
微服务拆分之后，服务之间的调用当出现错误的时候，一定会重试，但是为了不要下两次单，支付两次，需要所有的接口实现幂等。

幂等一般需要设计一个幂等表来实现，幂等表中的主键或者唯一键可以是transaction id，或者business id，可以通过这个id的唯一性标识一个唯一的操作。

 也有幂等操作使用状态机，当一个调用到来的时候，往往触发一个状态的变化，当下次调用到来的时候，发现已经不是这个状态，就说明上次已经调用过了。

状态的变化需要是一个原子操作，也即并发调用的时候，只有一次可以执行。可以使用分布式锁，或者乐观锁CAS操作实现。
 
服务拆分的规范五：接口数据定义严禁内嵌，透传
 
微服务接口之间传递数据，往往通过数据结构，如果数据结构透传，从底层一直到上层使用同一个数据结构，或者上层的数据结构内嵌底层的数据结构，当数据结构中添加或者删除一个字段的时候，波及的面会非常大。

 因而接口数据定义，在每两个接口之间约定，严禁内嵌和透传，即便差不多，也应该重新定义，这样接口数据定义的改变，影响面仅仅在调用方和被调用方，当接口需要更新的时候，比较可控，也容易升级。
 
服务拆分的规范六：规范化工程名（见文只意）
 
微服务拆分后，工程名非常多，开发人员，开发团队也非常多，如何让一个开发人员看到一个工程名，或者jar的名称，就大概知道是干什么的，需要一个规范化的约定。

 例如出现pay就是支付，出现order就是下单，出现account就是用户。

 再如出现compose就是组合层，controller就是接口层，basic就是基础服务层。

 出现api就是接口定义，impl就是实现。

 pay-compose-api就是支付组合层接口定义。

 account-basic-impl就是用户基础服务层的实现。
 
 
 
参考链接：https://mp.weixin.qq.com/s/mcBdtqBRQbY4D5i6G7o-7g