从微服务到云原生

        很多文章介绍云原生概念，说它包含微服务，又包含了其它几个方面的东西，还扯到文化层面、组织层面和技术层面，搞技术的人一听到公司文化问题和组织部门问题，就十分地晕眩，不能让我好好地坐下来写写代码、搞搞纯技术吗？

        记得微服务是2013年大火起来的，搞Java企业应用系统开发的人们都痴迷于这一新概念，从2014年到2018年我也特别喜欢弄这一个新架构，痴迷于MartinFlower那颗大树上的茂密藤曼，希望它杀死我面前的一切单体应用，一次次研读Chris Richardson的微服务架构系列文章，实际工作中使用了Dubbo和SpringCloud两个框架，总体感觉微服务架构的概念还是比较内聚的，SpringCloud在官网号称它是最完整的微服务框架：

         And don’t forget, no microservice architecture is complete without Spring Cloud ‒ easing administration and boosting your fault-tolerance.

        我们就用SpringCloud来看看微服务的主要概念：

• 服务注册与发现——Netflix Eureka
• 客服端负载均衡——Netflix Ribbon
• 断路器（容错）——Netflix Hystrix
• 服务网关——Netflix Zuul
• 分布式配置——Spring Cloud Config
• 分布式日志追踪——Spring Cloud Sleuth

         我所理解的微服务架构知识主要是这6个方面，其它的我都不关心，就算是这6个方面也不好实现，让我难受的是：

1. SpringCloud从Netflix接收过来的东西，名字都怪怪的，让人难受；
2. Netflix Hystrix断路器实际搞起来特麻烦，反正我就没真正去实现过；
3. Spring Cloud Config的实现也让人难受，在客户线上环境安装SVN或GitLab，真的有点怪怪的。
4. Spring Cloud Sleuth分布式日志追踪，开发人员不用不关心，运维人员不懂不关心，所谓的DevOps实际搞起来没那么融洽。

         很多技术主管和架构师都号称搞微服务，到底搞到什么程度了？我估计都是实际搞一半，吹嘘一半。但反过来讲，搞一半是不是就够了，我们最终目的不就是软件交付嘛，按时向客户交付，功能正确和性能可接受，界面不要太难看，解决企业和用户的实际问题，就是项目成功了嘛，客户管你是用单体架构还是微服务架构呢。

        还有，不是做互联网系统，而是给企事业做应用系统的，系统的特点是功能多、用户少，根本就没几个人来访问，所以流量大而要做负载均衡就谈不上，真正解决的问题其实就是大单体带来的开发维护难问题，按功能内聚原则分拆设计就好了，按大功能点搞成一个个微服务就OK，所以，做企业应用系统真正需要的微服务组件最少简化到：

•  服务注册与发现——Netflix Eureka
•  服务网关——Netflix Zuul

   所以，我们不是什么时候都要搞全家桶的，学习起来还是很痛苦的，根据20/80原则，公司至少有80%的人是混日子不学习的，对他们来说越简单越好，其实SpringMVC搞单体对他们来讲是最好的，只是奈何他们不是技术总监或技术经理。

        微服务讲了这么多，我们用SpringCloud框架或其它微服务框架开发了一个应用系统，搞了一堆微服务组件，怎么发布？怎么部署？

        翻遍Spring官网都不见有大篇幅介绍系统部署的文章， 好了，我认为云原生技术知识就是刚好来解决这个下半场的问题。上半场是开发测试，下半场是部署交付，软件公司难道不就是干这两件大事吗？

        能想到的有多少种部署方式：

        1）单机部署：把所有的微服务组件进程都部署在一台机器上，不行吗？操作系统本来就是可以运行多进程的，所以你喜欢自然行，但是这台机器故障垮了就全完了。

        2）多机部署：搞N台硬件服务器，安装上Linux系统，根据所有硬件的资源情况，精细规划各个微服务组件应该分布到哪些节点上去，然后手工去每台机器安装JDK，配置好各种环境，最后手工去部署jar或war，一个分布式集群就形成了，不行吗？可以，就是太累太烦。比如使用不同的JDK版本同时部署，手工搞特麻烦。

        3）虚拟机部署：虚拟机技术出世后，VMWare公司兴起，同样是N台硬件服务器，采用虚拟机方式部署，又方便一点，但是虚拟机的开销还是受不了，据说Heroku早期是采用这种方式部署的，现实中没听说有人采用过。

        4）容器部署：Docker技术横空出世，拉开了容器化大幕，基于容器的一系列开源技术系统不断涌现，应用程序发布打包成容器镜像文件，对集群中节点的主机系统依赖几乎微乎其微，本身开销相对虚拟机也是非常地小，基本上是目前默认采用的部署方式。

        那么微服务架构开发出来的应用系统需要怎样的部署技术呢?或者说云原生应用系统需要怎样的部署方式呢？

1.  容器化：以容器镜像文件方式发布，把对目标系统的依赖降低到最小；Docker镜像优雅地解决了这一问题。
2.  集群化：通过API向一个集群发布，而不需要关注到具体的一个个物理节点；K8s、Swarm都是管理容器集群的。
3.  服务编排：声明式容器编排技术，可以对集群中的容器进行自动动态的管理和调度；K8s、Swarm的主要功能就是负责容器编排的。
4.  服务发现：K8s和Swarm以及配套系统已经直接支持了服务发现，根本不用像SpringCloud那样自己去实现。
5.  负载均衡：K8s和Swarm也是直接支持了负载均衡，根本不用像SpringCloud那样自己去实现。
6. API网关：同样，基于K8s和Swarm一整套云原生基础系统，有现成的方案来支持API网关，如Traefik、NGINX Ingress Controller等，功能都非常强大。
7. 分布式配置：K8s直接支持，consul等系统也可以用来存放配置，通过配置文件变化监控工具，可以做到非侵入式配置方式，应用程序还是读取本地配置文件，比侵入式方式优雅多了。

        主要分析以上7个方面，对一般中小型云原生应用系统都足够了，用不着服务网格等更复杂的技术，如限流、熔断、良好的灰度发布支持等，一般企业应用系统没必要在这方面耗费精力。

        什么是云原生？管它什么是标准准确的定义，先把上面讲的上下半场都搞好了，系统开发发布敏捷起来了，能频繁地发布部署，一切自动化起来，方方面面都比以前好了，就自然理解云原生了。如果搞了一通这些技术，软件交付更糟糕了，那么说明你的系统很简单，用单体吧，合适才是最好的！