过去,我们运维着“能做一切”的大型单体应用程序。 这是一种将产品推向市场的很好的方式,因为刚开始我们也只需要让我们的第一个应用上线。而且我们总是可以回头再来改进它的。部署一个大应用总是比构建和部署多个小块要容易。
集中式:
分布式:
集群
分布式和集中式会配合使用。
我们在搭建网站的时候,为了及时响应用户的请求,尤其是高并发请求的时候,我们需要搭建分布式集群来处理请求。我们一个服务器的处理能力是有限的。如果用我们一台设备当作服务器,那么当并发量比较大的时候,同一时间达到上百的访问量。那服务器就宕机了。然后只能重启服务器,当出现高并发访问的时候,就又会宕机。所以我们需要更多的服务器来并行工作,处理用户的请求。那么问题来了,我们服务器运行的时候,怎么分发大量的请求给不同的服务器呢?一般会采用(1 apache+n Tomcat)或者服务器模式来分发并处理请求。或者采用nginx分发请求。
微服务是运行在自己的进程中的可独立部署的服务套件。 他们通常使用 HTTP 资源进行通信,每个服务通常负责整个应用中的某一个单一的领域。 在流行的电子商务目录例子中,你可以有一个商品条目服务,一个审核服务和一个评价服务,每个都只专注一个领域。
用这种方法让多语言服务(使用不同语言编写的服务)也成为可能,这样我们就可以让 Java/C++ 服务执行更多的计算密集型工作,让 Rails / Node.js 服务更多来支持前端应用等等。
微服务会成为大规模分布式应用的主流架构。任何复杂的工程问题都会归结为devide and conquer(分而治之),意思就是就是把一个复杂的问题分成两个或更多的相同或相似的子问题,再把子问题分成更小的子问题……直到最后子问题可以简单的直接求解,原问题的解即子问题的解的合并。微服务本质是对服务的拆分,与工程领域惯用的“分而治之”的思路是一致的。
两个平台 Spring Cloud 和 Kubernetes 非常不同并且它们之间没有直接的相同特征。
两种架构处理了不同范围的MSA障碍,并且它们从根本上用了不同的方法。Spring Cloud方法是试图解决在JVM中每个MSA挑战,然而Kubernetes方法是试图让问题消失,为开发者在平台层解决。Spring Cloud在JVM中非常强大,Kubernetes管理那些JVM很强大。同样的,它就像一个自然发展,结合两种工具并且从两个项目中最好的部分受益。
这里面哪些内容是我们可以拿掉或者说基于 Service Mesh(以 Istio 为例)能力去做的?分析下来,可以替换的组件包括网关(gateway 或者 Zuul,由Ingress gateway 或者 egress 替换),熔断器(hystrix,由SideCar替换),注册中心(Eureka及Eureka client,由Polit,SideCar 替换),负责均衡(Ribbon,由SideCar 替换),链路跟踪及其客户端(Pinpoint 及 Pinpoint client,由 SideCar 及Mixer替换)。这是我们在 Spring Cloud 解析中需要完成的目标:即确定需要删除或者替换的支撑模块。
如果不用 Spring Cloud,那就是使用 Spring Boot + K8S
无论是单体应用,还是分布式应用,都可以建立在Service Mesh上,mesh上的sidecar支撑了所有的上层应用,业务开发者无须关心底层构成,可以用Java,也可以用Go等语言完成自己的业务开发。
当微服务架构体系越来越复杂的时候,需要将“业务服务”和“基础设施”解耦,将一个微服务进程一分为二:
为什么代理会叫sidecar proxy?
看了上图就容易懂了,biz和proxy相生相伴,就像摩托车(motor)与旁边的车厢(sidecar)。未来,sidecar和proxy就指微服务进程解耦成两个进程之后,提供基础能力的那个代理进程。