微服务入门介绍

一，微服务架构背景介绍

 

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

 

1，传统垂直应用架构

LAMP架构 = Linux + Apache + PHP + MySQL；

MVC架构 = Spring + Struts + iBatis/Hibernate + Tomcat；

以MVC架构为例：

最前端是视图展示层（View）：主要用于前端Portal展示，使用的开发工具为JSP,JS，HTML+CSS等。视图向用户显示相关的业务数据，并能接收用户的输入。

中间为调度控制层（Control）：前端Web请求的分发，调度后台的业务逻辑执行，可以通过继承Struts的Action实现。

应用模型层（Model）：代表业务数据和业务执行逻辑。

随着业务的不断发展，应用规模日趋庞大，传统垂直架构开发模型的弊端变得越来越突出：

（1）复杂应用的开发维护成本变高，部署效率逐渐降低。

（2）团队协作效率差，部分公共功能重复开发。

（3）系统可靠性变差。随着业务发展，访问量逐渐攀升，网络流量，负载均衡，数据库连接等面临巨大压力。

 

2，RPC架构

RPC它是一种进程间通信方式。目标就是让远程过程调用更加简单，透明，RPC框架负责屏蔽底层的传输方式（TCP或者UDP），序列化方式和通信细节。

RPC框架实现的几个核心技术点总结：

（1）远程服务提供者需要以某种形式提供服务调用相关信息。

（2）远程代理对象。服务调用者调用的服务实际是远程服务的本地代理。

（3）通信。RPC框架与具体的协议无关。

（4）序列化。远程通信，需要将对象转换成二进制码流进行网络传输。

业务主流的RPC框架：

Facebook开发的远程服务调用框架Apache Thrift；

Hadoop的子项目Avro-RPC；

caucho提供的基于binary-RPC实现的远程通信框架Hessian；

Google开源的基于HTTP/2和ProtoBuf的通用RPC框架gRPC；

RPC框架面临的挑战：

（1）服务越来越多，服务URL配置管理变得非常困难，F5等硬件负载均衡器的单点压力也越来越大。

（2）随着业务的发展，服务间依赖关系变得错综复杂。

（3）服务的调用量越来越大，服务的容量问题就暴露出来了。

（4）服务化之后，随之而来的就是服务治理问题。

 

3，SOA服务化架构

SOA是一种粗粒度，松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。

面向服务设计的原则：

SOA面向服务的一般原则：

（1）服务可复用。

（2）服务共享一个标准契约。消费者和服务提供者交互，需要导入提供者的契约。

（3）服务是松耦合的。

（4）服务是底层逻辑的抽象。

（5）服务可组合，可编排。

（6）服务是自治的。

（7）服务是无状态的。

（8）服务是可被自动发现的。

 

4，微服务架构

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

微服务主要特征：

（1）原子服务，专注于做一件事。高内聚，松耦合。

（2）高密度部署。重要的服务可以独立进行部署，非核心服务可以独立打包，合设到同一个进程中，服务被高密度部署。

（3）敏捷交付。由小研发团队负责设计，开发，测试，部署，线上治理，灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。

（4）微自治。

 

微服务架构对比SOA：

（1）服务拆分粒度：SOA首先要解决的是异构应用的服务化，微服务强调的是服务拆分尽可能小，最好是独立的原子服务。

（2）服务依赖：SOA存在大量服务间依赖，微服务避免依赖其他服务产生耦合。

（3）服务规模：SOA服务粒度比较大，因此服务实例数比较有限；微服务尽可能拆分，同时很多服务会独立部署。

（4）架构差异：企业集成总线ESB（实总线）逐渐被P2P的虚拟总线替换。

（5）服务治理：静态治理转型为运行态微治理。

（6）敏捷交付：微服务实现真正的DevOps。

 

MVC架构：业务规模很小时，将所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流。

RPC架构：当垂直应用越来越多，应用之间的交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。

SOA架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。

微服务架构：随着敏捷开发，持续交付，DevOps理论的发展和实践，以及基于Docker等轻量级容器部署应用和服务的成熟，微服务架构开发流行，逐渐成为应用架构的未来演进方向。

 

二，微服务定义

 

 微服务解决了构建分布式系统的复杂度，由一系列互相独立可部署，小的，模块化的服务组成。微服务是可以一起工作的小的，自治的服务。

实际上微服务本身并没有严格定义，划分原则也有不同的实践，但是比较通用的划分原则是：微服务通常是简单，原子的微型服务，它的功能单一，只负责处理一件事，与代码行数并没有直接关系，与需要处理业务复杂度相关。

微服务4特点：

（1）单一职责原则：每个服务负责单一功能。

（2）独立部署，升级，扩展和替换：每个服务可以独立部署和重新部署而不影响整个系统。

（3）支持异构/多种语言：每个服务的实现细节都于其他服务无关，这使得服务之间能够解耦。

（4）轻量级：微服务通常由轻量级的分布式服务框架承载，采用P2P通信，无中心节点，性能可以线性增长。

微服务12原则：

（1）从一个代码库部署到多个环境。

（2）使用显式的声明隔离依赖，即模块单独运行，并可以显示管理依赖。

（3）在系统外部存储配置信息。

（4）把支持性服务看作是资源，支持性服务包括数据库，消息队列，缓冲服务器等。

（5）严格划分编译，构建，运行阶段，每个阶段由工具进行管理。

（6）应用作为无状态执行。

（7）经由端口绑定导出服务，优先选择HTTP API作为通用的集成框架。

（8）并发性使用水平扩展实现，对于web就是水平扩展web应用实现。

（9）服务可处置性，任何服务可以随意终止或启动。

（10）将日志看做是事件流来管理，所有参与的服务均使用该方式处理日志。

（11）开发和生产环境保持高度一致，一键式部署。

（12）管理任务作为一次性的过程运行。

 

三，微服务带来的改变

 

1，应用解耦

基于服务注册中心的订阅发布机制，可以实现服务消费者和提供者之间的解耦，消费者不需要配置服务提供者的地址信息，即可以实现位置无关的透明化路由，它的开发体验与本地API接口调用相似，但是却实现了远程服务的调用。通过服务订阅关系，业务和服务之间的调用关系变得透明化，不合理的接口依赖，调用关系一目了然。

 

2，分而治之

应用的拆分分为水拆分和垂直拆分两种，水平拆分以业务领域为维度，抽象出几个不同业务域，每个业务域作为一个独立的服务中心对外提供服务。领域服务可以独立地伸缩和升级，快速地响应需求变化，同时与其他业务领域解耦。

垂直领域拆分主要包括前后台逻辑拆分，业务逻辑和数据访问层拆分。业务垂直拆分之后，Web前台和后台采用分布式组网，通过分布式服务框架实现前后台业务调用。数据访问层服务可以选择和其他服务合设，也可以独立集群组网。

 

3，敏捷交付

微服务架构最显著的一点：敏捷性的产生，是将运行中的系统解耦为一系列功能单一服务的结果。微服务架构能够对系统中其他部分的依赖加以限制，这种特性能够让基于微服务架构的应用在应对Bug或是对新特性需求时，能够快速地进行变更。

 

优点总结如下：

1，开发，测试和运维更加简单

2，局部修改很容易部署，有利于持续集成和持续交付

3，技术选择更灵活，不与特定语言和工具绑定

4，有利于小团队作战，敏捷交付

 

四，微服务遇到的挑战

 

微服务架构对运维和部署流水线要求非常高，服务拆分的粒度越细，运维和治理成本就越高。

 

1，监控度量问题：海量微服务的各种维度性能KPI采集，汇总和分析，实时和历史数据同比和环比等。

 

2，分布式运维：服务拆分得越细，一个完整业务流程的调用链就越长，需要采集，汇总和计算的数据量就越大，分布式消息跟踪系统需要能够支撑大规模微服务化后带来的性能挑战。

 

3，海量微服务对服务注册中心的处理能力，通知的实时性带来了巨大的挑战。

 

4，微服务治理：微服务化之后，服务数相比于传统的SOA服务有了指数级增长，服务治理的展示界面，检索速度等需要能够支撑这种变化。

 

5，量变引起质变：传统的运维框架架构可能无法支撑，需要重构。