背??景我们过去常常运行“无所不能”的大型单片应用程序。这是将产品推向市场的好方法，因为我们只需要让我们的第一个应用程序开始运行。我们可以随时回过头来改进它。部署一个大型应用程序总是比构建和部署多个小应用程序更容易。Centralized:Cluster:Distributed:分布式和集中一起使用。我们在搭建网站的时候，为了及时响应用户的请求，尤其是高并发请求的时候，我们需要搭建一个分布式集群来处理请求。我们其中一台服务器的处理能力有限。如果我们其中一台设备作为服务器，那么在并发量比较大的时候，可以同时达到几百个访问量。然后服务器宕机了。那么就只能重启服务器了，等到高并发访问的时候，又会宕机。所以我们需要更多的服务器来并行工作并处理用户请求。那么问题来了，当我们的服务器运行时，我们如何将大量的请求分发到不同的服务器上呢？一般采用（1apache+nTomcat）或者server模式来分发处理请求。或者使用nginx分发请求。微服务是在其自己的进程中运行的可独立部署的服务套件。它们通常使用HTTP资源进行通信，每个服务通常负责整个应用程序的一个区域。在流行的电子商务目录示例中，您可以拥有产品列表服务、评论服务和评论服务，每个服务都只关注一个领域。Polyglot服务（用不同语言编写的服务）也可以通过这种方法实现，因此我们可以让Java/C++服务完成更多计算密集型工作，让Rails/Node.js服务更多地支持前端应用程序等。微服务将成为大规模分布式应用的主流架构。任何复杂的工程问题都会归结为devideandconquer（分而治之），就是把一个复杂的问题划分为两个或多个相同或相似的子问题，再将子问题划分为更小的子问题……until最后子问题可以简单直接的求解，原问题的解就是子问题解的组合。微服务的本质是服务的拆分，这与工程领域通常的“分而治之”思维是一致的。SpringCloudvs.K8S比较SpringCloud和Kubernetes这两个平台非常不同，它们之间没有直接的共同特征。这两种架构处理不同范围的MSA障碍，并且它们使用根本不同的方法。SpringCloud的方法是试图解决JVM中的每一个MSA挑战，而Kubernetes的方法是试图让问题消失并在平台级别为开发人员解决。SpringCloud在JVM方面非常强大，而Kubernetes在管理这些JVM方面非常强大。同样，将这两种工具结合起来并从两全其美中获益就像一个自然的过程。可以看出，几乎一半的关注点都与运维有关。从这个角度来看，将springcloud和kubernetes进行比较似乎有点不公平。springcloud只是一个开发框架，对于如何部署和调度应用无能为力，而kubernetes是一个运维平台。或许用springcloud+cloudfoundry来对比kubernetes更合理，但需要注意的是，即使加入了cloudfoundry的paas能力，springcloud仍然是“侵入式”和语言相关的，而kubernetes是“非侵入性“”和语言无关。SpringCloudvsIstio中有哪些内容我们可以根据ServiceMesh的能力（以Istio为例）去掉或做些什么？经分析，可以替换的组件包括网关（gateway或者Zuul，替换为Ingress网关或者egress），fuse（hystrix，替换为SideCar），注册中心（Eureka和Eurekaclient，替换为Polit，SideCar），负责平衡（Ribbon，被SideCar取代），链接跟踪及其客户端（Pinpoint和Pinpointclient，被SideCar和Mixer取代）。这就是我们在SpringCloud分析中需要完成的工作：确定需要删除或替换的支撑模块。可以说springcloud所侧重的功能是kubernetes的一个子集。可以看出，双方的解决方案都比较完善。在kubernetes这边，在Istio出来之前，只能提供最基本的服务注册和服务发现能力（服务只是一个4层转发代理）。Istio出来之后，已经具备了比较完善的微服务能力。在springcloud这边，除了运维平台的发布、调度、自愈等功能外，其他功能也得到了更全面的支持。相对来说，云厂商会更喜欢kubernetes方案，因为三个字：非侵入性。平台能力与应用层的解耦，让云厂商可以轻松升级和维护基础设施，而无需关心应用。这也是我比较看好ServiceMesh等技术前景的原因。如果SpringBoot+K8S不用SpringCloud，那就用SpringBoot+K8S。我不会介绍SpringBoot的基础知识。推荐这个实用教程：https://github.com/javastacks...这里需要介绍一个项目SpringCloudKubernetes，用于将kubernetes中的服务模型映射到SpringCloud。在服务模型中，使用SpringCloud原生的那些SDK，来实现kubernetes中的服务治理。具体来说，k8s中的services对应SpringCloud中的services，k8s中的endpoints对应SpringCloud的instances。这样就可以通过标准的SpringCloudAPI对接k8的服务管理系统。说实话，我个人认为这个项目的意义不是很大。毕竟都在k8上。K8本身已经具备比较完善的微服务能力（具备注册中心、配置中心、负载均衡能力），应用之间可以直接通信。调用，应用完全没有感知，你通过sdk调用，感觉有点多余。现在强调的是语言的非侵入性。SpringCloud的一个很大的局限是它只支持java语言（甚至更老的j2ee应用都不支持，只支持SpringBoot应用）。所以我个人觉得这个项目的使用范围在具体的业务服务层面是非常有限的。借助SpringCloudKubernetes项目，zuul可以以非侵入的方式提供API网关能力。应用完全不需要任何修改，网关是可插拔的。未来可灵活更换为其他网关产品。整体耦合度很低。得益于k8的服务能力，zuul甚至支持异构应用的接入，这是SpringCloud体系所不具备的。本身开发是基于java的，让java程序员可以很方便的基于zuul开发各种功能复杂的过滤器，而不需要去学习go或者openresty等不熟悉的语言。ServiceMesh的价值无论是单体应用还是分布式应用，都可以构建在ServiceMesh之上。网格上的边车支持所有上层应用程序。业务开发人员无需关心底层组成。他们可以使用Java或Go。等其他语言完成自己的业务开发。当微服务架构体系越来越复杂，需要将“业务服务”和“基础设施”解耦，将一个微服务进程一分为二：代理为什么叫sidecar代理？看了上图就很容易理解了，biz和proxy是相辅相成的，就像摩托车（motor）和边车（sidecar）一样。以后sidecar和proxy指的是微服务进程解耦为两个进程后提供基础能力的代理进程。Istio的理论概念是ServiceMesh（服务网络）。我们不必担心这个概念。它其实是微服务的一种实现形式，有点类似于上面的SideCar模型。它的主要思想是关注点分离，即不像SpringCloud交给研发，没有集成到k8s造成职责混乱，Istio提供服务发现、负拦截平衡、限流、微服务管理链接跟踪和身份验证等方法。Istio最初是结合k8s设计的。Istio结合k8s可以实现微服务架构。Istio超越了springcloud和dubbo等传统开发框架，因为它不仅带来了远超这些框架所能提供的功能，而且不需要对应用进行大量改动，开发者不用担心上面大量的改动知识是为功能实现而保留的。但是结论是，springcloud可以做到，那k8s+istio也可以吗？更好？
