微服务那些高大上的概念

微服务

概念

单体应用

LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring + iBatis/Hibernate + Tomcat。不管是 LAMP 仍是 MVC，都是为单体应用架构设计的，其优势是学习成本低，开发上手快，测试、部署、运维也比较方便，甚至一我的就能够完成一个网站的开发与部署。

微服务

把模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的形式对外提供服务。每一个微服务都严格遵循独立打包部署的准则，互不影响。好比一台物理机上能够部署多个 Docker 实例，每一个 Docker 实例能够部署一个微服务的代码。每一个微服务均可以交由一个小团队甚至我的来开发、测试、发布和运维，并对整个生命周期负责。

服务化拆分的两种姿式

• 纵向拆分：从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
• 横向拆分：从公共且独立功能维度拆分。标准是按照是否有公共的被多个其余服务调用，且依赖的资源独立不与其余业务耦合。

服务化拆分的前置条件

• 服务如何定义。对于单体应用来讲，不一样功能模块以前相互交互时，一般是以类库的方式来提供各个模块的功能。对于微服务来讲，每一个服务都运行在各自的进程之中，应该以何种形式向外界传达本身的信息呢？答案就是接口，不管采用哪一种通信协议，是HTTP仍是RPC，服务之间的调用都经过接口描述来约定，约定内容包括接口名、接口参数以及接口返回值。

• 服务如何发布和订阅。单体应用因为部署在同一个WAR包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，服务提供者该如何对外暴露本身的地址，服务调用者该如何查询所须要调用的服务的地址呢？这个时候你就须要一个相似登记处的地方，可以记录每一个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。

• 服务如何监控。一般对于一个服务，咱们最关心的是QPS（调用量）、AvgTime（平均耗时）以及P999（99.9%的请求性能在多少毫秒之内）这些指标。这时候你就须要一种通用的监控方案，可以覆盖业务埋点、数据收集、数据处理，最后到数据展现的全链路功能。

• 服务如何治理。能够想象，拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。好比一个服务的性能有问题时，依赖的服务都势必会受到影响。能够设定一个调用性能阈值，若是一段时间内一直超过这个值，那么依赖服务的调用能够直接返回，这就是熔断，也是服务治理最经常使用的手段之一。

• 故障如何定位。在单体应用拆分为微服务以后，一次用户调用可能依赖多个服务，每一个服务又部署在不一样的节点上，若是用户调用出现问题，你须要有一种解决方案可以将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联全部路径，从而进行故障定位。

微服务组件

服务描述

服务调用首先要解决的问题就是服务如何对外描述。好比，你对外提供了一个服务，那么这个服务的服务名叫什么？调用这个服务须要提供哪些信息？调用这个服务返回的结果是什么格式的？该如何解析？这些就是服务描述要解决的问题。简单来讲就是接口文档。

经常使用的服务描述方式包括RESTful API、XML配置以及IDL文件三种。

注册中心

你提供了一个服务，如何让外部想调用你的服务的人知道。这个时候就须要一个相似注册中心的角色，服务提供者将本身提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所须要调用的服务的地址，而后发起请求。

服务框架

服务通讯采用什么协议？就是说服务提供者和服务消费者之间以什么样的协议进行网络通讯，是采用四层TCP、UDP协议，仍是采用七层HTTP协议，仍是采用其余协议？

数据传输采用什么方式？就是说服务提供者和服务消费者之间的数据传输采用哪一种方式，是同步仍是异步，是在单链接上传输，仍是多路复用。

数据压缩采用什么格式？一般数据传输都会对数据进行压缩，来减小网络传输的数据量，从而减小带宽消耗和网络传输时间，好比常见的JSON序列化、Java对象序列化以及Protobuf序列化等。

服务监控

一旦服务消费者与服务提供者之间可以正常发起服务调用，你就须要对调用状况进行监控，以了解服务是否正常。

服务追踪

你还须要记录服务调用通过的每一层链路，以便进行问题追踪和故障定位。

服务治理

服务监控可以发现问题，服务追踪可以定位问题所在，而解决问题就得靠服务治理了。服务治理就是经过一系列的手段来保证在各类意外状况下，服务调用仍然可以正常进行。好比自动扩缩容，就能够用来解决服务的容量问题。