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