随着业务的发展，应用规模不断扩大，系统内部的巨无霸应用越来越多，常规的垂直应用架构已经无法应对复杂 业务带来的各种挑战。通过将业务公共能力抽象成原子服务，对复杂应用进行水平拆分和服务化，实现服务消费者和提供者的解耦。公共能力抽取和复用，可以有效降低公共模块的复用开发建设成本。

传统垂直型应用架构

在2006年之前，业界比较流行的有：LAMP架构，即Linux + Apache + PHP（前后台界面和业务逻辑） + Mysql数据库（读写分离）；MVC架构，即Spring + Struts + iBatis/Hibernate + Tomcat；厚重的EJB企业架构也刘兴国很长一段时间。

传统垂直型应用架构优点：

垂直应用架构技术比较单一，学习成本低，开发上手较快，测试、部署和运维也比较简单，因此在很长一段时间里都占据着统治地位。

传统垂直型应用架构弊端：

但随着业务不断发展，应用规模日趋庞大，传统垂直架构开发模式的弊端变得越来越突出，具体如下：
1.复杂应用的开发维护成本变高，部署效率主键降低。
2.团队协作效率差，部分公共功能重复开发，代码重复率居高不下。
3.系统可靠性变差。
4.维护和定制困难。
5.新功能上线周期变长。

RPC架构

RPC的全称是Remote Procedure Call，它是一种进程间通讯方式。允许想调用本地服务一样调用远程服务，他的具体实现方式可以不同，例如Spring的HTTP Invoker，Facebook的Thrift二进制私有协议通信。

主流的开源RPC框架非常多：

1.由Facebook开发的远程服务调用框架Apache Thrift
2.Hadoop的子项目Avro-RPC
3.caucho提供的基于binary-RPC实现的远程通信框架Hessian
4.Google开源的基于HTTP/2和ProtoBuf的通用RPC框架gRPC

RPC架构优点：

1.简单
2.高效
3.通用

RPC架构面临的挑战：

1.服务越来越多时，服务URL配置管理变得非常困难。
2.随着服务发展，服务间的依赖关系变得错综复杂。
3.服务的调用量越来越大，服务的容量问题就暴露出来了。
4.服务上线容易下线难，上线前的审批，下线前的通知。
5.服务化之后，随之而来的就是服务治理问题。

SOA服务化架构

SOA是一种粗粒度、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。SOA帮助工程师们站在一个新的高度理解企业级架构中各种组件的开发和部署形式，他可以帮助企业系统架构师以迅速、可靠和可重用的形式规划整个系统。

SOA架构设计原则：

1.服务可复用
2.服务共享一个标准七月
3.服务是松耦合的
4.服务是底层逻辑的抽象
5.服务是可组合、科比安排的
6.服务是自治的
7.服务是无状态的
8.服务是可被自动发现的

SOA服务治理：

1.分布式框架下的服务调用性能
2.服务化架构如何支持线性扩展
3.如何实现高效、实时的服务多维度监控
4.大规模分布式环境下的故障快速定界和定位
5.分布式环境下海量日志在线检索、模糊查询
6.服务的流控、超时控制、服务升降机等管控手段
7.服务的划分原则，如何实现最大程度复用

微服务架构

微服务架构（MSA）是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。

微服务主要特征：

1.原子服务，专注于做一件事
2.高密度部署
3.敏捷交付
4.微自治

微服务与SOA相比差异：

1.服务拆分粒度：SOA首先要解决的是异构应用的服务化，微服务强调的是服务拆分尽可能小，最好是独立的原子服务
2.服务依赖：传统SOA服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是服务自治、功能单一独立，避免依赖其他服务产生耦合，耦合会带来更高的复杂度
3.服务规模：传统SOA服务力度比较大，多数会采用将多个服务打包一个war包的方案，因此服务的实例数比较有限；微服务强调尽可能拆分，同事很多服务会独立部署，浙江导致服务规模急剧膨胀，对服务治理和运维带来新的挑战。
4.架构差异：微服务化之后，服务数量的激增会引起架构质量属性的变化，为了保证高性能、低延时，需要高性能的分布式服务框架保证微服务架构的实施。
5.服务治理：传统基于SOA Governance的静态治理转型为服务运行态微治理、实时生效。
6.敏捷交付：服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。

本文摘自《分布式服务框架》一书。