自从《序》发表之后20多天了，新项目总算忙过去了，回家过年顺便休个假，茶余饭后继续我们的九周九分布式服务系列文章。根据预告中的顺序，今天写第一篇《架构演进》，书归正传。
00 概述
随着业务的发展，项目的规模不断扩大，为了方便快速的构建迭代应用，应用的架构也在不断的演进，发展的核心问题是，服务化改造和服务治理。这种架构设计是，对复杂的应用进行水平拆分和服务化改造，将服务的消费者和服务的提供者解耦，增加复用性，减少公共模块的重复开发。系统可靠性和团队的协作能力也会有所提高。
应用架构的历史演进过程是这样的，下图展示了整个过程。
- 垂直烟囱式架构：这类架构一般是一个war包搞定一切 [All in One]。
- RPC架构：这类架构实现了前后端分离，这里不是指页面（html等）和后台代码（java等）的分离，是指逻辑上的前后端分离，前端逻辑和后端逻辑的分离，前端逻辑由Spring MVC框架完成，后端通过RPC框架完成业务逻辑接口的封装和暴露。
- SOA架构：随着暴露接口的增多，在RPC架构中接口的管理和配置工作随之增加，这时对应用的架构提出了更高的要求，服务自动发现，自带负载均衡，服务自治，服务可编排等高级特性。这就是面向服务的架构设计（SOA）出现的历史原因。
- 微服务架构：与SOA架构没有本质上的区别，是SOA架构进化出来的一种服务设计风格，特点是服务拆分粒度小、服务量大、真正实现敏捷交付、践行DevOps思想。
01 垂直架构
这种架构设计一般出现在业务发展初期，业务功能单一，业务量小。 在垂直的架构中一般采用经典的MVC三层架构模型：
垂直的mvc三层架构，最前端的是视图展示层，是用户与之交互的界面；中间的控制层主要负责web请求的分发；第三层为应用模型层，这是业务逻辑的主要实现部分。
它的部署方式一般是如下形式：
特点：
维护成本高，部署效率低，团队协作效率差，导致系统可靠性变差（在一个进程里面，一旦有一个接口出现故障，内存泄漏，会影响整个节点的宕机），新功能上线周期变长（耦合太多）。
02 RPC架构
RPC全称是Remote Procedure Call，是一种进程间通信方式，允许像调用本地服务一样的调用远程服务，一定程度上做到了公共服务的重用。支撑这种架构的框架就是RPC框架，业界流行的开源的RPC框架主要有：
- FaceBook主导开发 Apache Thrift
- Hadoop子项目 Avro-RPC
- Caucho提供的Hessian
- Google开源的gRPC（HTTP/2、protobuf）
在java的语言环境中，实现原理中用的主要技术包括序列化、socket通信、动态代理、反射机制。其实徒手实现一个简单RPC框架也是不复杂的，主要是由三个部分组成：
- 服务提供者：运行在服务端，负责服务接口的定义和实现。
- 服务发布者：运行在RPC服务端，负责将本地服务发布成可远程调用的服务。
- 本地服务代理：运行RPC客户端，负责通过代理调用远程服务，将返回结果封装好供本地消费者使用。
RPC架构一般的部署方式：
RPC框架的特点：简单、高效、通用，是SOA架构发展的底层技术支撑。
RPC架构的特点：一定程度上提高了服务的重用性，但是消费者调用服务提供者配置管理困难，并且消费者无负载均衡控制，调用关系梳理困难。
03 SOA架构
SOA是面向服务架构，是一种粗粒度的、以服务为中心的架构。业界流行的框架：
- Dubbo/Dubbox（阿里/当当开源）
- HSF（阿里商业版）
- DSF（华为商业版）
- Coral Service（亚马逊内部）
- Spring Cloud（pivotal开源/商业版）
在上述框架中大家最熟悉的应该是Dubbo框架，Dubbo框架的官方文档写的非常好，学习分布式服务框架必读文档。
SOA架构的应用部署方式：
与上面RPC架构的图相比，其中多了两个翅膀，不要小看这两个翅膀，它们为我们的服务开发和运维工作提供了很多便利，起到了为应用保驾护航的作用。
特点：
在服务注册中心的协助下实现了，服务自动发现、统一配置、可配置的服务路由、可配置的集群容错机制、服务治理等；服务治理也是依赖服务注册中心实现的，和具体的服务消费者和提供者是松耦合的，服务治理包括：服务运行态管控、服务生命周期管理、服务监控、服务安全、服务故障快速定位等功能；为运维工作提供了极大的便利。
04 微服务架构
微服务架构是一种服务化的架构风格，对服务的拆分粒度更细。微服务架构诞生肩负了更多的责任，最大限度的利用IT资源，容器化部署，敏捷交付以及自动化运维等。
上面一张ppt基本概括了微服务的一切，应该是盖住了。。。
结束语：第一篇写于家中文章，回头看看还可以，本文主要写的是一个发展过程，还是宏观的东西多一点，循序渐进，后面会慢慢深入进去。
