我的服务公共化实践

服务公共化也算是一种标准化，它是线上的技术架构标准化。

之前有一篇讲了运维标准化是运维的基础，更是运维自动化的基础。但我觉得高效运维的关键是第二阶段---架构服务化更是关键，此项工作的深入推动需要运维和研发强力配合，这种配合不仅仅是技术和执行层面上的配合，有时候还需要一些部门文化和目标层面上的配合。为了强力推进这部分的工作，有时候甚至需要运维自己组建公共服务的研发团队。在小的IT企业中，大家对这块的认识应该不会太深刻，到一个中等规模（比如说多个产品线、服务器千台规模以上等等），此时更需要架构的公共能力服务化来形成技术架构的标准化，从而解决IT服务的效率和运维问题。有时候，你可以把这个服务化理解成PAAS平台化的一部分。

备注：相同服务的多组件会导致服务质量下降，组件引入的越多，对研发、测试和运维的要求越高，很难找到这种多组件能力的维护团队；业务的敏捷性要求越来越高，传递给后端技术服务能力也要越来越敏捷，这个时候只能公共化服务能力才能满足这一要求，把这种服务能力变成一种自服务的能力，变成一种api的能力；运维管理必须以可运维性为目标，把技术架构中的公共服务能力打造到极致，比如说mysql、cache、文件存储的服务等等。

备注：这是一个通用的互联网技术架构，不做详述。

备注：在通用架构中，架构中的点和线如果选型不当或者技术把控不足，就会带来以上的技术失控（Out Of Control）。对于每一层的技术架构来说，我们组件选型会泛滥，其实这种泛滥许多时候都是基于团队或者个人的偏好来进行的，而不是真正的合理评估。在一个完全没有接维的IT组织中，这种情况更是比比皆是，所以说有时候还是需要中心化的管理。一个离散式的组织中，必然会打来混乱和选型失控的情况。这个地方要注意线的失控，所谓线的失控就是服务间调用的失控，有些是通过lvs、有些是通过dns、有些是通过配置文件等等，如果有可能完成统一的标准制定，比如说我现在在UC用的就是名字服务中心。

备注：我在统计学的角度也做了一个解释，组件越多，每个组件的维护能力下降，带来的可用性必然是很低，由此多组件构建的技术架构可用性是一个乘积效应。在失控组件数量N大于可控组件数量M的情况下，前者的可用性必然是低于后者的。

备注：公共服务化也有标准的实现路径可循，对于一个不复杂的业务来说，其实基本上可以按照1.识别--》2.抽象--》3.选型--》4.实现--》5.接入推广几个阶段来完成。其中关键是第四步实现，这个地方就需要一个很强有力的技术实现小组来完成，肯定会出现的一种情况是，初步实现没法满足所有业务的需求，甚至是有些业务的需求根本就没有预估到，那么需要技术实现小组，边接入边优化。这次我们在把MC切到内部的分布式cache服务上就遇到了这类问题，只能在接入过程中，快速实现。这也是公共服务化的一个好处，研发能力的快速支持，当作一个产品来做。

备注：核心能力是【可运维性】，可以分解到不同维度上【服务透明】【可管理性】与【自服务】。【服务透明】是提供一种内在的容错机制、去状态的位置透明服务能力；【可管理性】，需要把运维的核心场景可视化实现，比如说数据迁移、cache扩缩容等等；【自服务】是想把这种服务能力提供给所有人，甚至给周边的一些业务系统，供其api直接调用。

备注：在来UC的一年多时间里，基本上把技术架构中公共需求都统一切到公共服务平台上。目前这些平台对某个运维人的依赖越来越低。在非运维主导的这块，还有服务间调用解耦用到的【飞鸽系统】与统一消息推送系统【飞雁系统】。在技术架构里面，我们正在和研发推动统一的业务灰度发布系统、统一服务降级系统、语音实时消息公共平台。

备注：以上两个图，是我们的统一分布式cache服务---浮云，用来替换memcache，传统的memcache散落在各个业务的服务器上，完全的组件化能力，需要每个人掌握memcache的运维能力，切换到统一的浮云后，一切运维能力可视化，在线管理变更、在线状态查询、在线统计的分析等等。最关键的是，这套技术架构更考虑可运维性的要求，比如说容灾容错等等，甚至是跨机房之间的cache数据同步都在这层解决。

备注：

【公共架构团队】，必须要有一个公共架构团队，不过这个公共架构团队，适当的需要纳入业务研发团队的成员，避免需求偏离。

【强有力的领导】，没有强有力的领导，这套技术标准很难推行。

【架构和运维的深度融合】，不管是技术上的融合，还需要在团队间合作上的融合。

【一致的方向理解】，大家需要形成一致的方向理解能力，认同统一的目标和方向。这个一致的理解不仅仅是在研发和运维之间，甚至是研发团队之间。

【持续的目标认同及滚动】，不可避免在切换的过程中或多或少会出现一点问题，前提是我们必须做好灰度控制。过程中出现的问题，不应该成为阻碍，我们需要承认这种临时的不完美，然后持续向前滚动。

备注：以前想在九游这边所有业务推动webP图片压缩，碰到一个现实的问题，图片存储不集中，没法要求所有的研发团队处理。现在我们把所有的图片能力接管以后，我们做webP图片的压缩，完全不依赖业务方的实现，由图片云统一处理。这是一个公共服务化后，让IT组织技术成本更低的一个例子。

总结：一定要记得避免选型泛滥，这个泛滥后面就需要来打扫战场，非常痛苦。服务公共化是运维团队必须迈出去的一步，这一步事关后面的无状态的技术架构实现。在运维侧，基本上现在我们公共服务的维护都只需要一个人负责，大大降低了运维成本。在研发侧，他们对运维的需求接口更简单了，服务更专业化。最终我们想做到的目标是，研发只需要编写业务逻辑代码就好了，其他的各个专业服务基于客户端Library的Api调用即可。