程序员的三体世界

从千万级架构到大数据人工智能中台的讨论

程序员的三体世界

序言

第一节面试

第二节大数据已标准化，人工智能还是人工智障

第三节中台

旁白

序言

当你真正的明白程序员是什么，你们还引以为傲吗，你们还想入门吗？

第一节面试

王秒第一次当面试官，他的理想是成为一名出色的架构师。他从很早就开始使用各种语言做程序员了，他可以说是最早的一代全栈，他能用N种语言写不用版本的hello world。他也一直在研究软件服务架构，朝着所谓的宏观架构去努力。这次面试他提前查看了面试者的资料，是一个刚刚工作不久的小伙子。王秒不想为难那人，面试本来就是相互交流的过程的，他准备了一些在生产过程中遇到的问题打算一起交流讨论，也看看那个人的脑筋思路。他刚走近会议室，就听到那个人正和另一位面试官侃侃而谈。

“你们怎么做到一个秒杀服务的高性能高并发高可用？”。

“我们使用Redis做缓存做数据预热，然后再用LVS加个网关加个Nginx集群 KeepAlived。然后我们使用springboot做个微服务，springcloud全家桶管理。然后服务间再做个异步化，异步化引入RocketMQ，然后保证RocketMQ 的一致性，在本地写一套事务表，和本地事务夹杂在一起，然后RocketMQ有个回调机制，用回调机制保证两边的幂等性”。

“那你们怎么做Redis间的高可用？”

“redis高可用，有redis sentinel 和 redis cluster的，我们现在用redis cluster，redis cluster 是怎么做hash分片的，crc16嘛，循环校验码，然后做一个hash，虚拟hash环，解决分布不均匀的问题”。

“你们的发布部署怎么做的？”

“部署嘛，我们引入CICD，首先我们代码放在gitlab集群，代码从gitlab里面拉下来，然后通过Jenkins，做一键部署，打包镜像，写dockerfile，然后打包发布到hub包，最金丝雀发布或蓝绿发布，然后蓝绿发布之后再做的滚动升级”

… ...

“一言不合Redis，上来就是微服务”这还能有错，面经上都是这么教的，没去过大厂但肯定是这么做的了。没有问到我算法，算了，分治法，动态规划法，回溯法，分支界限法，贪心法，LeetCode我也都刷过了”面试的小伙子得意的离开了。

王秒最终没有参加面试，他没有打断这个面试者，这个小伙子说的一点毛病都没有，但是又总感觉哪哪都不对，他陷入了沉思。按照这个逻辑，所有的架构都已经可以清晰的做标准化了，一切都已经设定好了，不需要再有人去创造了，程序员只需要搬砖就可以了，架构师也只是空谈了。

王秒仔细想了一下小伙子刚刚的表现，内心更加细致的描述了一下现在的所谓千万级亿级流量系统的模板，“无非nginx，keepalived，或先搭一个lvs，lvs上面搭一个DNS轮训，轮训再打到不同的nginx，nginx最后再打到网关。之后网关上一层要在进入一个ip清洗层；网关打过来有eureka，再加个限流，可以用 hystrix或sentinel。然后服务间用feign，在从eureka中拿过来，再用ribbon做负载调用。后面应该是一个服务集群，集群上面每一个服务再用skywalking，知道服务做了什么，然后再用sentinel或hystrix做短路保护和限流。然后有eureka做了一个注册中心，能够支持一个多机化集群调用；后面再加一个配置中心，可以动态修改spring里面的内容，把服务放到k8s里面跑。最后面在加一个mysql + ha 的集群，再加一个mongo 集群，再加个es集群，redis -cluster集群。缓存一致性加个rocketmq，再做个异步更新；”

... ...

第二节大数据已标准化，人工智能还是人工智障

按照一切都是标准化的逻辑，王秒仔细梳理了一下其他的架构，发现一切都是那么可怕。

大数据的核心

大数据早已经不是几年前摸索的阶段，一切早是标准了。大数据中最标准的架构，输入-输出-任务中心-调度中心。Hadoop、flink、spark，这三个之后storm还可以做流处理，数据存储用dfs，自带的flink，也可以用Hadoop，Hadoop用yarn还是用MapReduce，在来个hive...

人工智能人工智障

目前比较神秘的还是人工智能，研究也有一段时间了。这难道不是标准吗，或是一些人正让他在趋向标准。TensorFlow，写个python，然后调神经网络，然后调调参，然后神经网络里面的参数微调，出来一个递归，出来一个线性回归法，然后看看数据拟合了，好像是人工智能了。这到底是人工智能还是人工智障?

第三节中台

王秒最近在探索中台的意义，好多公司也都在搞中台。到底什么是中台，该不该搞中台，搞中台必死，中台已死吗?会不会也是一个标准化了。搞中台真的有意义吗？他又想了很多。

很多人也都很明白，先想清楚我们的商业模式是什么，抽象和提炼出我们的企业的最佳实践，然后在复用，这是中台的精髓，从“去重”到“复用”，从“治理”到赋能，从“技术视角驱动”到“业务价值驱动”。中台应该是企业级“业务模式”复用平台。

但是话好多事难做，困难就在于所谓的“业务模式”，业务的共性，很容易被感知，确很难被界定。

中台是在国内阿里率先提出的，“大中台小前台”，中台就像大炮，前台就像步兵，这可以火力灵活的覆盖到敌人任何阵地角落。阿里真正的拥有亿级流量千亿级流量，很多业务的共性确实可以让其快速的包装另一层身份。但是这样的企业国内甚至全球有几家，一般的中小型企业平时连个蚊子都碰不上，用的着架设火箭炮吗？也是确实有不少公司，宣称自己做成了中台，也有数据中台，业务中台，但是你们确定那是中台而不是一个灶台？

阿里有其他企业无法比拟的规模，所以其自然发展必有演变，我们可以借鉴他如下的双中台设计提升思路，而不是完全仿造。让数据业务化，业务数据化，从而提升智能时代的效率。但是这真的适合我们所有人吗？

当互联网兴起，大流量进入，所有人都在跟风分布式微服务，好好的一个单体，拆分的七零八落，1个人的事让10个人去做。当中台提出，一个接一个微服务全叫中台。到最后美其名根据康威定律又要拆分组织，一个服务无奈被分到N个组织，这时候根据人的惰性就开始推脱扯皮，1天完成的事就又得让项目经理帮着协调到100天才完成。最后呢，这个中台架构师又出来了，又不好意思拉黑中台打自己的脸，这样吧，前端应该机动灵活，应该一定程度自己控制数据，NodeJs加MongoDB嘛。恩完美，我们应该发展全栈工程师。