一、微服务与SOA
“微服务”是一个名词，没有这个名词之前也有“微服务”，一个朗朗上口的名词能让大家产生一个认知共识，这对推动一个事务的发展挺重要的，不然你叫微服务他叫小服务的大家很难集中到一个点上。
业界对微服务与SOA的区别争论比较多大多都是在微观上对比他们的区别什么微服务粒度更细啊、微服务没有ESB啊、微服务通讯相比SOA采用更轻量级的协议啊等等，但是从微观谈区别本身就有悖论，
这些区别只是微服务的一种”最佳实践“而已。我个人理解微服务与SOA灵魂上的不同是
微服务是互联网时代的产物而SOA是系统集成的产物，微服务是对系统的打散而SOA是对系统的整合。
二、 微服务与SpringCloud
因为SpringCloud的流行很多人就把SpringCloud等同于微服务，这也没有错共识的人多了就是对的。准确点说SpringCloud是适合实现微服务的一套基础框架，SpringCloud有助于讯速的落地微服务架构。SpringCloud是以Java库的形式工作所以它的工作层面是在应用层（研发层）。
SpringCloud通过提供一篮子解决方案来应对微服务中的各种需求和通点，通过Eureka提供服务注册与发现，Ribbon实现客户端的负载均衡，Feign牛逼的将REST变成强类型的接口调用，Config提供方便但不灵活的配置中心，Hystrix提供熔断方案，Zuul提供网关方案等。
优点：
1、提供较全的微服务治理全套解决方案
2、对开发人员友好（对代码侵入强）
缺点：
1、只能java平台技术栈使用，当然提供了SideCar用于集成异构技术但是限制比较大
2、对开发人员友好（对代码侵入强）
三、Kubernetes(k8s)
k8s并不是因为微服务而生而是因为docker而生只是天时地利人和正好赶上了微服务流行的时代，docker的特性正好特别适用于微服务，而k8s进一步对docker方便的编排。
从基础设施方向来讲k8s可以比作是IDC机房和机房工作人员，对物理服务器（docker）的存放与管理，上机架、装系统、接网络等等。
从微服务的角度来讲，k8s通过基础设施的方式通过逻辑抽象出service等概念提供了对微服务的另一种实现，就好比用N台电脑联网提供了FTP服务。
优点：
1、在基础层提供了抽象，对代码无侵入
缺点：
1、对微服务治理比较弱，如熔断限流等，当然这也不应该是k8s做的。
四、Istio
Istio的理论概念是Service Mesh（服务网络），我们不必纠结于概念实际也是微服务的一种落地形式有点类似上面的SideCar模式，它的主要思想是关注点分离，即不像SpringCloud一样交给研发来做，也不集成到k8s中产生职责混乱，Istio是通过为服务配 Agent代理来提供服务发现、负截均衡、限流、链路跟踪、鉴权等微服务治理手段。
Istio开始就是与k8s结合设计的，Istio结合k8s可以牛逼的落地微服务架构。
优点：
1、关注点分离，对代码无侵入
2、服务治理相关较全面
缺点：
1、老子学不动了
五、我理想中的微服务架构
