我终于搞懂了微服务，太不容易了... _微服务

微服务是什么?抛去教条性质的解释，从巨石应用到微服务应用，耦合度是其中最大的变化。

文章插图
图片来自 Pexels
或是将多个模块中重复的部分进行拆分，或是纯粹为了拆分膨胀的单体应用，这些拆分出来的部分独立成一个服务单独部署与维护，便是微服务了。
拆分后自然而然会催生出一些必要的需求：

从本地方法调用的关系衍变成远程过程调用的关系，那么可靠的通信功能是首要的。
随着拆分工作的推进，资源调度关系会变得错综复杂，这时候需要完善的服务治理。
调用关系网的整体复杂化还会给我们带来更大的风险，即链式反应导致服务雪崩的可能性，所以如何保障服务稳定性也是微服务架构中需要考虑的。
这点就不是内需而算是自我演进了，服务化后，如果能结合容器化、Devops 技术实现服务运维一体化，将大大降低微服务维护的成本，不管是现在还是将来。

微服务是什么样的
从目前常见网站架构的宏观角度看，微服务处在中间的层次。红框圈出的部分都属于微服务的范畴。

文章插图

包括最基础的 RPC 框架、注册中心、配置中心，以及更广义角度的监控追踪、治理中心、调度中心等。

文章插图

从微服务自身角度来看，则大致会包含以下这些模块:

服务注册与发现
RPC 远程调用
路由与负载均衡
服务监控
服务治理

服务化的前提
是不是只要套上微服务框架就算是一个微服务了呢?虽然这样有了微服务的表，但却没有微服务的实质，即“微” 。
微服务化的前提是服务拆分到足够”微“，足够单一职责，当然拆分程度与服务边界都需要结合业务自行把握。
广义的服务拆分即包含了应用拆分，也包含了数据拆分。应用拆分后需要引入微服务框架来进行服务通信与服务治理，这也就是传统定义上的微服务。
数据拆分后同样需要引入一系列手段来进行保障，由于不是与微服务强相关的话题，在此只做简单阐述：

分布式 ID
新表优化
数据迁移与数据同步
SQL 调用方案改造
切库方案
数据一致性

具体的微服务请求背后
在我们对微服务架构有了整体的认识，并且具备了服务化的前提后，一个完整的微服务请求需要涉及到哪些内容呢?
这其中包括了微服务框架所具备的三个基本功能：

服务的发布与引用
服务的注册与发现
服务的远程通信

服务的发布与引用
首先我们面临的第一个问题是，如何发布服务和引用服务。具体一点就是，这个服务的接口名是啥，有哪些参数，返回值是什么类型等等，通常也就是接口描述信息。
常见的发布和引用的方式包括：

RESTful API/声明式 Restful API
XML
IDL

一般来讲，不管使用哪种方式，服务端定义接口与实现接口都是必要的，例如：

@exa(id = "xxx") public interface testApi {@PostMApping(value = https://www.isolves.com/it/cxkf/jiagou/2020-06-12/"/soatest/{id}")String getResponse(@PathVariable(value = "id") final Integer index, @RequestParam(value = "str") final String Data);}

具体实现如下：

public class testApiImpl implements testApi{@OverrideString getResponse(final Integer index, final String Data){return "ok";} }

声明式 Restful API：这种常使用 HTTP 或者 HTTPS 协议调用服务，相对来说，性能稍差。
首先服务端如上定义接口并实现接口，随后服务提供者可以使用类似 restEasy 这样的框架通过 Servlet 的方式发布服务，而服务消费者直接引用定义的接口调用。
除此之外还有一种类似 Feign 的方式，即服务端的发布依赖于 SpringMVC Controller，框架只基于客户端模板化 HTTP 请求调用。
这种情况下需接口定义与服务端 Controller 协商一致，这样客户端直接引用接口发起调用即可。
XML：使用私有 RPC 协议的都会选择 XML 配置的方式来描述接口，比较高效，例如 Dubbo、Motan 等。
同样服务端如上定义接口并实现接口，服务端通过 server.xml 将文件接口暴露出去。服务消费者则通过 client.xml 引用需要调用的接口。