学不动了古典、SOA、传统、K8S、ServiceMesh( 二 ) _SOA

4、微服务v1.0——传统服务框架玩法

文章插图

上图是大多数RPC框架的架构图。大多数早期的微服务实践都是RPC的方式，最近几年Spring Cloud盛行后其实Spring Cloud的玩法也差不多，只是Spring Cloud推崇的是JSON over HTTP的RESTful接口，而大多数RPC框架是二进制序列化over TCP的玩法（也有JSON over HTTP的RPC）。
其实RPC框架我个人喜欢JSON over HTTP，虽然我们知道HTTP和JSON序列化性能肯定不如一些精简的二进制序列化+TCP，但是优点是良好的可读性、测试方便、客户端开发方便，而且我不认为15000的QPS和20000的QPS对于一般应用有什么区别。
总的来说，我们会有一个集群化的分布式配置中心来充当服务注册的存储，比如ZK、Consul、Eureka或etcd 。我们的服务框架会有客户端和服务端部分，客户端部分会提供服务的发现、软负载、路由、安全、策略控制等功能（可能也会通过插件形式包含Metrics、Logging、Tracing、Resilience等功能），服务端部分对于RPC框架会做服务的调用也会辅助做一些安全、策略控制，对于RESTful的话就服务端一般除了监控没有额外的功能。
比如使用Spring Cloud来玩，那么：

Service Discovery：Eureka、Open Feign
Load Balancing：Ribbon、Spring Cloud LoadBalancer
Metrics：Micrometer、Spring Boot Actuator
Resilience：Hystrix、Resilience4j
Tracing：Sleuth、Zipkin

在之前《朱晔和你聊Spring系列S1E8：凑活着用的Spring Cloud（含一个实际业务贯穿所有组件的完整例子）》一文中，我有一个完整的例子介绍过Spring Cloud的这套玩法，可以说的确Spring Cloud给了我们构建一套微服务体系最基本的东西，我们只需要进行一些简单的扩展和补充，比如灰度功能，比如更好的配置服务，就完全可以用于生产。这种模式和之前0.x的很大区别是，服务的注册有一个独立的组件，注册中心完成，通过配合客户端类库的服务发现，至少服务的扩容很轻松，扩容后也不需要手动维护负载均衡器的配置，相当于服务端从死到活的一个重大转变。而且在1.0的时代，我们更多看到了服务治理的部分，开始意识到成百上千的服务，如果没有Metrics、Logging、Tracing、Resilience等功能来辅助的话，微服务就是一个灾难。
Spring Cloud已经出了G版了，表示Netflix那套已经进入了维护模式，许多程序员表示表示扶我起来还能学。我认为Spring Cloud这个方向其实是挺对的，先有开源的东西来填补空白，慢慢再用自己的东西来替换，但是开发比较苦，特别是一些公司基于Spring Cloud辛苦二次开发的框架围绕了Netflix那套东西来做的会比较痛苦。总的来说，虽然Spring Cloud给人的感觉很乱，变化很大，大到E到G版的升级不亚于在换框架，而且组件质量层次不齐，但是它确实是一无所有的创业公司能够起步微服务的不多的选择之一。如果没有现成的框架（不是说RPC框架，RPC框架虽是微服务功能的80%重点，但却是代码量20%的部分，工作量最大的是治理和整合那套），基于Spring Cloud起步微服务，至少你可以当天起步，1个月完成适合自己公司的二次开发改造。
5、微服务v2.0——容器+K8S容器调度玩法

文章插图

K8S或者说容器调度平台的引入是比较革命性的，容器使得我们的微服务对环境的依赖可以打包整合进行随意分发，这是微服务节点可以任意调度的基础，调度平台通过服务的分类和抽象，使得微服务本身的部署和维护实现自动化，以及实现更上一层楼的自动伸缩。在1.x时代，服务可以进行扩缩容，但是一切都需要人工介入，在2.x时代，服务本身在哪里存在甚至有多少实例存在并不重要，重要的只是我们有多少资源，希望服务的SLA是怎么样的，其余留给调度平台来调度。
如果说1.0时代大家纠结过Dubbo还是Spring Cloud，2.0时代我相信也有一些公司上过Mesos的“贼船”，我们不是先知很难预测什么框架什么技术会在最后存活下来，但是这却是也给技术带来了不少痛苦，相信还是有不少公司在干Mesos转K8S的事情。
如果引入了K8S，那么服务发现可以由K8S来做，不一定需要Eureka 。我们可以为Pod创建Service，通过Cluster虚拟IP的方式（如上图所示，通过IP tables）路由到Pod IP来做服务的路由（除了Cluster IP方式也有的人对于内部连接会采用Ingress方式去做，路由方面会更强大，不过这是不是又类似v0.2了呢？）。当然，我们还可以更进一步引入内部DNS，使用内部域名解析成Cluster IP，客户端在调用服务的时候直接使用域名（域名可以通过配置服务来配置，也可以直接读取环境变量）即可。如果这么干的话其实就没有Eureka啥事了，有的公司没有选择这种纯K8S服务路由的方式还是使用了注册中心，如果这样的话其实服务注册到注册中心的就是Pod IP，还是由微服务客户端做服务发现的工作。我更喜欢这种方式，我觉得K8S的服务发现还是弱了一点，而且IP tables的方式让人没有安全感（IPVS应该是更好的选择），与其说是服务发现，我更愿意让K8S只做容器调度的工作以及Pod发现的工作。