《Microservices》

不被各种新概念牵着鼻子走是技术人员最基本的素养之一。

从某种程度上来说，“微服务”也只是个“把戏”概念。单纯地列举“微服务”的优缺点简直就是在耍流氓。

前言综述

简单来说，微服务架构是一种将单应用拆分部署为多个子服务的架构形式。

这些子服务运行各自独立的进程中，它们之间通常使用 HTTP API 之类的轻量级机制进行通信。

这些子服务通常围绕具体的业务能力设计，可独立地部署。

微服务架构与单体式架构其实没有本质区别——它们都是构建服务。

这同工程管理中将一个超级工程拆分成多个多级子工程进行管理是相通用的。

拆分成多个子服务的最主要好处是便于专注地精细化管理，而不用将太多资源耗费在“集成”系统上。

如：因为精力与能力有限，实际上他只能负责具体某一块子系统业务；

如果让应用服务设计为单体式架构，他可能需要花很多精力用于各种沟通协调。

但是在微服务架构中，因为“微服务”这个概念已经迫使这个研发组织划分出各组件（子服务）之间明确的职责界限（合作契约），所以他可以将更多精力投入到自己负责的子服务业务中。

微服务架构（vs 单体式架构）之所以那么火，很大程度上就是因为有非常多的人有非常不切实际的想法——用伺候单个微服务的资源去 hold 住整个应用；

而且投资方（老板）又全都有这种不切实际的想法，所以更容易引发资源不足的矛盾。

大工程当然复杂，当然难做！

拆分成微服务后成本会下降吗？会，也不会！就看你是怎么算这笔账的。

如果你是想把工程做成功，那么拆分成微服务管理这条路会比单体式架构那条路更容易达到这个目标。（长期而言，微服务路线成本更低）

但是把现有单体式架构改造成微服务肯定要继续追加大量资源。（短期而言，转型需要追加投资）

现实情况往往是资源配比远不足以切换到微服务架构模式

但是，历史无法假设无法重来，同一个工程不可能用两种架构各完成一遍再来计算所耗资源。

非常重要的一点是：我们永远无法得知走另一条路所需成本的精确值。

虽然有一些模型可以用来预测概况，但人总是选择性地相信自己想要相信的事。

既想马儿跑，又不想给马吃草？没这样的好事。

明白工程成本上的事就更能了解其实很多我们所说的微服务架构特征未必真的是特征，单体式架构也一样可以有这些属性；

只是相比而言，在微服务架构中，这些属性一般会稍显眼一些。

特别是当人们有这些特征属性需求，而微服务架构又刚好可以更低成本实现这些需求时，这些属性就愈发显得是特征了。

单体式架构

企业级应用通常由三部分组成：

• 客户端：负责面向用户的交互；
• 服务端：接收并处理来自客户端的请求；
• 数据库：用于存储业务数据

在单体式架构模式下，服务端就是一个可运行的单元，所有服务端逻辑都可以放到一个进程中运行。

水平扩展方面，可以运行多个服务端实例，通过负载均衡器进行管理。

单体式架构的优点（微服务架构的缺点）

这些特点反过来就是微服务架构的缺点，其实也差不多就是分布式系统的缺点（CAP理论是注定会面对）。