土味微服务
前段时间有大佬邀请，参加了一个微服务方面的交流，期间大放厥词，回味起来意犹未尽，整理一稿出来，博诸君一哂。
扯一扯定义
单体应用（monolithic application）这个名词，是经常被拿出来和微服务做比较（吊打）的。知己知彼百战不殆，在说微服务之前，似乎蛮有必要了解一下这个老对手的情况。
按照 Google 程序员的常用抄袭手段，我在 Google 搜索 monolithic application，选一点结果摘录如下：
In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.
Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.
根据上面的陈述，会发现很难对单体应用做出一个精准的判断，single program、single-tiered 放到真实世界中，除了单服务器、单进程的小网站之外，这种情况似乎很难看到。在面对几十几百台服务器的时候，我想大概没有架构师会有兴趣让几百台服务器都跑同一个 WAR 吧。
对手身份不太明确，那么会不会是个兔死狗烹呢？微服务的定义又是什么样的呢？下面是 Martin Folwer 给出的定义：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
小有多小，轻有多轻，全自动的范围有多大，去中心化到底有怎样的自治，似乎也都让人摸不到头脑。
虽说概念没有一清二楚，然而从上述的定义来看，微服务是对一些既有的观点进行了强调的：
- 以业务为中心
- 多技术栈共存
- 轻量协议互访
- 去中心化
据此，我对微服务这个风向的理解，是在传统软件的设计开发体系基础之上的一种变化，相对于翻天覆地的变革，我更愿称之为一种改良。
是谁坑了瀑布流程
人人喊打的瀑布流程，在我看来，面对的是一种类似读书时候经常提到的理想状况：
在理想状况中：
- 需求是清晰而持久的
- 基础设施都是稳定的
- 依赖服务都是靠得住的
过往的开发过程在这种理想状况中，是具备非常多的好处的：
- 单一的技术栈有利于人才招聘、培养以及技术积累。
- 少量的业务进程对发布、运维都有较小的压力，并且内部调用效率更高。
- 集中数据的好处更是车载斗量，安全、事务等方面有极大的优势。
然而世界发生了变化，廉价服务器包打天下，IT 人满坑满谷，业务日新月异，新技术层出不穷，用户漫山遍野，这一切因素叠加起来，都让以前重如千钧的需求变得相当轻浮。
结果现在越来越多的开发过程，变成了这样：
所有的环节，都随时面临变化的冲击：
- 既有需求尚未完成，已经产生变更。
- 设计开发过程受到新技术新方法的冲击。
- 测试标准、交付标准的变化。
- 运行环境升级和故障响应要求。
种种变化归结起来：
硬件和人力都变得廉价，变更频繁并且范围更大。
快速的变化除了产生需求之外，还让黏连在一起的大进程难于适应：
- 不同业务之间的信任关系会发生变化。
- 共享数据容易污染。
- 多小的代码变更，都可能引发大量的测试和上线动作。
- 特定业务场景无法使用最优技术栈进行实现。
- 必须同步进行缩放。
除了上述的外部因素之外，开发团队和交付物自身其实也同样的不理想：
- 牵一发而动全身的共享代码库。
- 不严格的组件边界，可能导致不同业务互相干扰。
应对思路也顺理成章：
- 越长的流程越容易被变化击中，换句话说，越短的流程越容易完成。
- 缩短的流程，决定了交付物体积缩小，但是并行开发的需求大增。
- 并行开发的过程，要求有多团队协同工作。
- 多团队的结果就会导致扩展技术栈、去中心化的要求。
更小的交付物，和更便宜的服务器勾搭起来，产生了大量运行小进程的廉价服务器，自然也就催生了“民用”的分布式计算。
如此一来，各种集群、各层协议、各种分布式框架就成了刚需，产生了空前发展。
从“集中力量干大事”，到“各村有各村的高招”，这种变化自然是为了满足客户需要。
没有 Silver Bullshit
按照前面提到的思路，我们：
- 把进程内的组件拆成独立服务。
- 独立的服务运行各自的进程。
- 原有的进程内调用变成了网络调用。
- 各个服务可能采用不同的技术栈来实现。
- 每个服务独占存储自己的存储。
大的有点不好，小的就一定好么？各自放飞的微服务，有了各自的实现、发布、伸缩的弹性，是不是就一定好了？
- 更多的服务器，和相关设施，代表着更多的故障。所以微服务经常强调的是面向故障进行设计。
- 分离的数据，相对于原有的单一数据库来说，事务保障变得复杂无比。
- 大量的进程会给运维工作带来很大压力，急需监控和自动化的大力支持。
- 单一业务的调用序列大幅延长，调试优化难度也一定是大大增加了。
- 散乱的技术栈，会大幅提高技术管理的难度，降低知识的复用性。
- 独立的代码库，很明显会降低代码复用的可能性。
由此看来，这种拆分并非只赚不赔的好买卖。是一个需要权衡的事情。不论微服务的数量有多大，个头有多小，作为一个独立的交付物，都还是需要遵循既有的软件开发技能和规律的。那么问题来了——对于给定的系统，到底应该有多少个微服务，每个服务有多大呢？
前文说道，我更愿意称微服务为一种改良，他是一种应对变化的手段，而非特征。在如今的情况下，不管是对新业务实现的设计，还是对既有系统的重构，任何架构师都不会把明明应该拆分的东西硬性的合并到一起。所以这个分离的标准就比较重要了。
拆还是不拆，这是个问题
很明显的，微服务的设计不是一个靠数量取胜的事情，所以重点不是能拆成多少块，而是什么东西需要拆，下面列出我所知的几个影响因素。
组织机构
利益人的识别，在各种软件开发过程中都是很重要的一个环节，在微服务中也是如此，而且尤其重要。当一份交付物存在多个利益人，并且互相之间不存在管辖关系的时候，就表明当前交付物的边界出现了问题，面临着令出多头、需求干扰的风险。
伸缩需求
同一个进程之内的不同业务功能，有时在业务量方面会出现较大的差异，具体要求的进程数量会有较大差别，这样的模块锁定在同一进程之内，势必会造成资源的浪费。
部署频率
这个很容易理解，同一个交付物内不同的组件有着不同的上线频率，会大大的提高上线流程的发生频率，会造成较大的人员浪费。
修改的相关性
如果同一交付物内的不同组件，经常会被同步修改，这可能说明，如果发生拆分，这两个模块应该是”在一起“的。
技术栈
新技术的爆发，让很多不同的场景有了更好的实现方式，如果有业务急需使用新的技术栈来（重新）实现。这种新技术除了新的语言、新的数据库之外，可能还包括容器、Service Mesh、API 网关等新晋 PaaS 能力。毫无疑问，这种业务也同样有拆分的需要。
结论
微服务虽说不是一个全新的东西，但也绝非是简单的新瓶装旧酒。总体说来，我认为这是在尊重现实，适当妥协的基础上，一种应对变化的好办法。
参考
崔秀龙
简单，是大师的责任；我们凡夫俗子，能做到清楚就很不容易了。