图解服务化架构演进

前言

  随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算势在必行，对

现阶段传统垂直架构改造的核心就是对应用做服务化改造，服务化改造使用的核心技术架构就是分布式服务框架。

服务化架构演进

        那什么是微服务架构呢？

        orm – 单一应用架构：是一个高内聚版本，所有功能部署在一起。数据访问框架（orm）成为关键。这个架构很少被人使用，几乎接近灭绝了吧。  优点：成本低，适合功能少又简单
缺点：很多，比如无法适应高流量，二次开发难，部署成本高。

        mvc架构 － 垂直应用架构：当访问量渐渐增大，慢慢演化成用的很多的mvc架构。虽然还是所有的功能都是部署在同一个进程中，但是可以通过双机或者前置负载均衡来实现负载分流。这样应用也可以拆分成不同的几个应用，以提升性能和效率。此时，mvc架构用于分离前后端逻辑。一方面，有一定的模块化。另一方面，加速和方便了开发。

        rpc架构 － 分布式服务架构：当mvc垂直应用分成不同应用时，越来越多的情况下。不可避免的事应用a与应用b之间的交互。此时将核心和公共的 业务功能抽出来，作为单独的服务，并实现前后端逻辑分离。此时则就需要提高业务的复用及整合的分布式rpc框架。

        soa架构 － 流动计算架构：当rpc架构中的服务越来越多时，服务的生命周期的管控，容量的评估等各种问题会出现，使服务化成为瓶颈。需要增加一个调度中心来进行对服务管控，监督等。

       微服务架构：对于微服务，我们可以简单的理解成对一个服务解耦，以降低业务系统的复杂性，将服务系统中的功能进行拆分成多个轻量的子服务，各个自服务间通过RPC实现服务间的关联，这样做的好处是将业务简单化，每个子服务可以有自己独立的编程语言，模式等且能够独立维护，独立部署，功能复用。下面是对微服务架构的图解：