分布式微服务架构四个阶段
单一应用架构:ORM
垂直应用架构:MVC
分布式架构:RPC
弹性式架构:SOA
从2000年开始，互联网在中国开始盛行。那时候网民比较少，网站流量也比较少。我们只需要一台机器就可以运行所有的服务。也就是说All in One的一个单体架构就能够满足需求。
随着网站的访问量增加，一旦服务器，或者是数据库出现问题，就会但只整个系统出现故障，造成所有的服务都不可用，而功能修改发布也不那么方便，所以就把大系统需要拆分成小系统比如说将用户，商品，订单按照业务来进行拆分这也就是垂直拆分，并且每个子系统都要部署到不同的服务器上去。
随着用户访问量继续增大，意味着需要更多的服务器，才能够支撑服务的运行。而应用之间的交互有不可避免的变得越来越复杂，为了去保证服务的稳定性，提高管理的效率，我们需要对这些服务做一个负载均衡，因为用户，他不可能去了解后台的服务器的数量和业务的结构，有了负载均衡以后，用户只需要去统一访问到负载均衡服务器就可以了。那么后端的应用，可以根据流量的大小进行动态的扩缩容，也就是水平扩展。
那在分布式架构运行一段时间以后，我们发现商品和订单服务中有很多重复的功能，比如SSO,OAuth权限校验，还有支付等等，那一单项目大了，集群部署的服务器也多了，这些重复的功能，无疑就变成了资源的浪费，我们就需要把这些重复的功能单独处理处理，进行单独部署，并且给他们起了个名字叫做Service（服务）。我们并且对服务进行分层，比如说：Base Service基础服务，Business Service业务服务等等。
我们有了这些服务的概念之后，还可以根据业务需要，将服务进一步进行细化和拆分，比如说用户服务：可以分为用户积分服务，个人优惠卷服务等等，这就是我们通常所说的微服务架构。
但是往往对于微服务架构实际上没有一个明确的定义，因为微服务的边界很难去确定，所以微服务架构一直在不断的重构过程中进行发展，没有完美的微服务架构，只有适合公司的业务场景的微服务架构。
服务网络
在Java中，微服务架构主流的解决方案是SpringCloud，SpringCloud也给程序员带来了非常便捷的开发体验，
但是有了SpringCloud微服务架构，我们就发现微服务架构带来的问题：
1.非功能性代码侵入比较严重：为了满足用户的业务需求，我们可以使用框架提供给我们的各种组件，比如说网络通信，消息处理等等。于是我们就需要引入各种以来加注解写配置，然后将这些非功能性业务代码和业务代码一起打包部署，这就成了侵入式框架。
2.微服务架构他的学习成本比较大，框架开发属于非业务内容
3.维护成本更高：互联网公司他的版本升级是非常频繁的，因为SpringCloud是侵入式的代码框架，为了去维护各个版本之间的兼容性，比如说：权限，流量等等。 版本升级的过程，就注定会让非业务代码跟着一起升级，再加上很多语言之间的一个调用，出现问题就很痛苦，服务拆分得越细，只是感觉上解偶了，但是维护成本变高了。怎么解决：服务网格技术诞生，也就是Service Mesh
我们可以为每个服务单个部署一个Sidecar，说到服务通信，它的进出口流量，都会通过Sidecar来进行操作，我们常见的服务网格产品 有Prana，Local Proxy，Linkerd 和Isio等等
目前主流的是Istio，其架构分为数据平台和控制平台，数据平面就是ServiceA和ServiceB的一个组织部分，控制平面主要指的是Mixer，Pilot，Galley和Cidatel等组件
这些组件部署到服务器有难度，基础设施和操作系统有差异，需要使用容器化技术来进行部署
3.容器化云原生架构
在架构演进阶段，我们可以基于容器化和容器编排技术来实现公有云或者是私有云还有混合云，它进行一个无缝迁移，可以使用云原架构来考虑组件和服务的一个部署方案。
通过这张图理解，不管地层的基础设施是什么，都可以使用Kubernetes来进行适配，就可以帮助开发，运维人员去屏蔽底层的硬件的细节，同时可以采用Devops来打破传统的开发和运维之间的界限。
从单体架构时代到云原生时代，每次架构演进，都会出现新词，比如分布式，微服务，云原生，都是为了程序员更加便捷开发。
