最近总听周围的人提微服务。

为什么使用微服务？微服务解决了什么问题，带来了什么问题？

个人情况

现在除了大数据，人工智能，区块链三驾马车之外，互联网比较火的技术词汇基本就是DevOps，微服务，中台这些了。

去年在大数据工作的时候，除了了解了大数据，做了一丁点基础的统计学人工智能（只有个线性回归…）之外，结果最多的其实是运维的东西。

大数据工作人员主要分三个部分：

• 开发工程师主要写ETL做数据清洗，和DBA的工作多少有点点类似，就是设计表，用类SQL语言做一些数据分类，归纳，清理的工作。什么spark, hadoop, storm其实就是干这事的，ES, HBase就是特殊的数据库，细节不提，大致工作内容是可以理解的。当然还有一些前端可视化，API接口的开发，埋点设计开发等，和传统WEB开发区别不算太大。

• 数据科学家主要做模型设计，特征归纳等。这个东西需要数学功底，了解一些统计学算法以及对数据的敏感性，主要是将一些业务需求进行拆分归整，多少类似一点数值策划。

• 架构师。其实这块就和运维越来越像了，他们负责整个体系的设计，到底用什么数据库，数据流向怎么跑的，用什么数据处理平台，同时一般都要负责这些数据库数据处理平台的基本搭建和基本维护。我想说的就是这里，其实软件和平台的搭建以及维护，在传统开发观念中是属于运维的范畴，这里就交给了开发，某种意义上，就已经属于了DevOps。

于是我也接触了一些，Linux操作也被迫搞了不少，K8S的pod设计yaml配置，docker的使用都在这个过程中有一些涉及。

以上，为我对微服务的理解做了第一层铺垫。

另外，我现在在网站开发部，C++很难有用武之地，PHP,JS,JAVA大行其道。我想自己不被开除，只能找条路子，于是这个机会我接触了最近比较火的golang。

用了一段时间之后，发现这东西做中小型web服务器还是非常方便的。而作为web服务器，肯定不会是单一架构，是分布式的，于是又用上了docker和k8s，期间惊喜的发现docker就是golang写的，于是对它也做了一点研究。

所以，我又进一步对微服务产生了兴趣。

外部局势

其实，在互联网行业，它还是个新生儿，2014年被提出来。但是发展的很快，大家都对他很有兴趣。

它的特点就是有高度灵活性，跨语言，强大的解耦性。

它的机遇和JAVA一样，出生的时候，解决的当时公司面临的很多问题，所以发展的非常快。

• JAVA当时就解决了高级程序员难招，低级程序员可能毁代码的问题，那么我设计一种语言，让菜鸟也会很快写出一个基本能用的代码，那么公司都会很喜欢吧，于是隐藏内存问题，顺道解决当时头疼的跨平台问题，再给你一堆简单易用的库，无论新手老手，大家都能愉快的来堆积木，所以JAVA混的很爽。

• 而微服务则解决了应用越来越复杂，变化越来越快，项目越来越庞大难以维护的这种问题，顺道也解决了现在各种语言太多，难以协作的问题，所以它看起来挺有未来。

现在它发展迅速，各个公司都相继开发了自己的开发框架和服务化套件。例如netflix的 spring cloud，以及谷歌IBM基于Service mesh开发的Istio，微软的Service Fabric，还有国内比较出名的阿里的dubbo，腾讯的tars等等。

国内互联网一直有个习惯，“跟潮流”，那怕跟那潮流没一点关系，也要擦个边蹭个风头，估计是为了忽悠外行，好拉投资吧，反正不是我关心的内容。总之，很多公司都号称自己用了微服务。

那微服务是啥？

很多人的认知就是最简单的理解，微小，服务。把系统进行接口化封装，然后拆掉，业务模块之间的调用给改成restful api调用，高大上一点的就改成rpc调用以达到“解耦合，功能单一微小，服务化”的目的。

这样改造的后果是，系统复杂度有可能增加，调试成本增加；而且函数调用的性能和网络IO的性能根本不是一个量级，反而性能受损。

所以，这并不是微服务的设计目的。那么，到底什么是微服务，它是适合什么场景的？

发展历史

说到这个，我想起来之前做游戏服务器时候的一些过程。

• 早期我在做游戏服务器的时候，还没有服务器组架构的概念，大家都是一个服务器负责全部功能。

这样的优势是开发简单快捷，调试也非常方便，部署非常简单。

但缺点逐渐就出来了，单服务器性能太差，随着玩家越来越多服务器压力越来越大。

• 于是，出现了平行扩容的服务器组的概念，将部分功能分离出来，创建多个副本以进行分压。

这样可以支持更高的并发。

但这种设计要求 服务的无状态化设计（restful api），对部署的扩缩容提出了更高的要求，对负载均衡与容灾都提出了更高的要求。

• 中间也出现过SOA服务架构，我没用过这种模式，不细说。

• 现在出现了微服务架构设计。

它有更强的扩展性，开发起来更加敏捷灵活。

但其缺点就是整个服务的管理跟踪问题，BUG的跟踪调试，运维难度都有提升。

解决方案

微服务的最大特点是“服务拆分”“跨语言RPC”，这些其实大部分公司都是做到了，但是微服务带来的其他问题，很多公司却没有完美处理，这些问题包括

• 复杂的部署，细粒度的资源分配，和如何便利的扩缩容。

解决方案：K8S+Docker

• 复杂的服务开发和服务集成

解决方案：Pipline

• 海量的服务治理

解决方案：Traefik

• 如何解决服务事务的依赖

解决方案：各种分布式事务

• 如何解决服务注册发现

解决方案：Consul

• 快速问题排查

解决方案：各种微服务框架，例如spring cloud, dubbo, istio都自带了。

当然，现在这些问题都有了对应的解决方案，只有这些都用好了，才算真正意义上的微服务架构，而不仅仅是一个“API接口化”。

与游戏应用的结合

在之前的日志中我已经记录了一些用户画像分析，流失人员预测等大数据分析的技巧，其实这些都是为游戏服务的。

今日头条之所以会战胜腾讯视频，原因就是进行精准定位，而这种方式在之后的游戏中一定会大行其道，你经常玩PVP？那就多给你推荐PVP的礼包。你打一个精英关卡打不过？那给你推荐合适的大腿。你这几天游戏很不顺？抽奖抽不到，组队遇菜鸟，那就给你送一些福利。

而这种活动，关怀行为，通常是独立的，临时性的。就非常适合进行微服务化。

对于平台化的游戏，更是十分适合扩展。

过了一晚上，不想写了，GG