微服务架构到底是什么样的？从不同的背景、不同的角度出发，就会有不同的理解。本文作者从做桌面程序开发，然后直接跳到基于云的开发，对于基于PaSS（微软的Service Fabric）和Kubernetes的微服务开发有一些经验。然后作者在架构师训练营课程中又跟着老师走了一遍，怎么从大型单体架构的网站、大型分布式系统开发背景下演化到微服务架构。这个两个角度相互补充，可以更完善对微服务架构的一些认知。
Dubbo
先上一个微服务框架实例。Dubbo是阿里开源的，基于java的高性能RPC微服务框架。Dubbo主要有三部分构成，服务注册中心，服务消费者和服务提供者，如下图所示。
服务提供者在服务注册中心注册其提供的API，服务消费者在本地调用服务API，这时候有本地的接口代理通过服务框架客户端来获取远端的服务者，然后通过通讯模块获取服务。在这个过程中消费者不关心API调用是本地还是远端，这个过程都有Dubbo框架给封装了。下图是反应该过程的一个时序图。
从桌面系统开发到微服务开发，跳级让人迷失
当年进入微服务领域时，上来就学单体架构有什么弊端，微服务是什么，怎么设计微服务等等。微服务的好处也能说的上来一些，但其实并没有什么切身体会。大的桌面系统也有编译慢、维护升级复杂等问题，但当时的觉悟就是，只要把一个大系统分成几个小的系统就行了，至于微服务框架提供的那些功能，也不知为啥提供。
开发自己的微服务系统时，用的是K8S。按照标准的程序，给每个微服务提供Deployment和Service，通过Service Name调用其他微服务的接口；通过Ingress（或者再配置一个API网关）把集群内的一些服务接口暴露给外面的用户。觉得者就是理所当然的这么做，至于为什么要这样，也是一知半解。
从Web、分布式系统到Web Service、微服务，有演进历程更容易理解
但从Web、分布式系统、Web Service，再到微服务，就明白了为什么K8S提供Service/Ingress，也知道了微服务框架的基本架构要素。从服务注册与发现这个基本要素出发，微服务架构也出现了像有RPC架构发展而来的ZeroC IceGrid，Java平台上的Spring Cloud，基于消息队列的异步微服务框架等等。