微服务是什么

抛去教条性质的解释，从巨石应用到微服务应用，耦合度是其中最大的变化。或是将多个模块中重复的部分进行拆分，或是纯粹为了拆分膨胀的单体应用，这些拆分出来的部分独立成一个服务单独部署与维护，便是微服务了。

拆分后自然而然会催生出一些必要的需求：

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

微服务是什么样的

从目前常见网站架构的宏观角度看，微服务处在中间的层次。红框圈出的部分都属于微服务的范畴。包括最基础的rpc框架、注册中心、配置中心，以及更广义角度的监控追踪、治理中心、调度中心等。

image.png

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

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

image.png

服务化的前提

是不是只要套上微服务框架就算是一个微服务了呢？虽然这样有了微服务的表，但却没有微服务的实质，即”微“。微服务化的前提是服务拆分到足够”微“，足够单一职责，当然拆分程度与服务边界都需要结合业务自行把握。

广义的服务拆分即包含了应用拆分，也包含了数据拆分。

应用拆分后需要引入微服务框架来进行服务通信与服务治理，这也就是传统定义上的微服务。

数据拆分后同样需要引入一系列手段来进行保障，由于不是与微服务强相关的话题，在此只做简单阐述:

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