你能读懂微服务架构深度解析：架构设计背后的哲学吗？(1)

小即是美

====

在软件的设计开发过程中，软件系统的规模很容易膨胀，工程师喜欢将纷繁复杂的功能全部堆积在一个程序中，这样的好处是代码唾手可得。然而，根据二八法则，实际运行中的代码其实往往只占到我们代码量的 20%。所以，切忌将大而全的工程作为我们的目标，相反，我们应该将功能设计成为实用且简洁的小程序。

在我的职业生涯中，经历过很多设计复杂、规模庞大的单体系统。有的是基于 C++编程语言的后端大型系统，有的是使用 J2EE-XML 编程风格、交织着庞大功能模块的巨石型应用，这些项目通常由 10 人以上的研发团队负责，动辄百人/月的开发计划。这种大型单体系统在上线后，时常发生系统内存溢出、系统宕机等问题，让开发人员心惊胆战。往往一个小问题会影响整个系统的正常运行，排查解决过程需要检查整个工程的代码逻辑，开发人员疲于解决生产上线后的各种问题和 Bug 修复。

事实证明，我们需要将庞大、复杂的系统分解成小程序。正如 UNIX 系统中强调的 KISS（Keep it Simple and Stupid）原则，可以说整个 UNIX 系统都是由数目众多的小程序组合完成各种复杂的操作系统功能的。每个小程序只完成其中一小部分功能。表面上，这些小程序都很低效，但是正是通过像搭积木一样将不同功能的小程序通过变换顺序和组合的方式，完成了各种意想不到的丰富而强大的功能。

小程序之美体现在响应变化上。通过小程序可以将这种改变控制在足够小的范围，保证不会给整个系统带来巨大的影响。

小程序之美体现在工程结构的简化和完备上。当你的程序充满了个性化的反射调用和程序员独特的编程思维痕迹，那么应该反省你的代码是不是已经脱离了小程序应有的代码简洁和易于理解。

小程序之美体现在性能优势上。小程序对外部的依赖少，从而可以快速启动，基于资源收敛式的反应式编程模型可以提升性能并减少资源浪费。

小程序之美体现在团队合作和独立演进上。清晰的边界划分是团队协作的有效手段，而体现在微服务架构上就是服务提供者和消费者可以预先订立契约，可以根据契约独立、并行开发各个服务，这样就实现了服务之间的解耦，使其功能能够独立进化。

做好一件事

=====

小程序应该只做好一件事，应该保持对一件事的专注力。在 UNIX 设计哲学中，解决一个问题并将问题解决到完美，比同时解决多个问题更为重要。然而在我们的工程中，随着项目的进展，我们很难将庞大的代码库进行清

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

晰的模块划分，更糟糕的是我们很多时候并不知道这些模块之间的服务界限。

在 UNIX 操作系统中，我们可以发现很多命令的强大之处正是只有单一的功能，并将这件事干好，也就是所谓的“Do one thing，do itwell”。而且 UNIX 首创的管道可以把这些命令任意地组合，以完成一个更为强大的功能。这些哲学到今天都在深深地影响着整个计算机产业，下面我们罗列一些经典的 UNIX 命令程序，如下表所示。

微服务的目标是独立地完成一件事并做到最好。微服务可以根据业务的边界来确定应用的行为，这样它不仅可以很容易地确定某个功能逻辑对应的代码，而且由于该服务专注在某个边界之内，因此可以更好地避免由于代码库过大衍生出的复杂性问题。

快速建立原型

======

只做好一件事的小程序可以让我们的项目轻装前行，我们不必再担心系统会成为一个庞然大物而无法控制。对于单体巨石应用，需要制定周密的计划去编写设计文档，以及为聚合不同模块之间功能而准备脚本和代码，相比之下，自治的小程序更加清楚自己的业务职责和业务范围。开发人员可以对小程序快速建立原型，缩短服务的交付周期，迅速构建可以供用户使用的程序和服务，并从结果中得到反馈，向最终的目标前进。

在 UNIX 设计哲学中，软件发生变化是不可避免的，这种变化来源于沟通的失败、需求理解的差异、知识经验的限制等，所以软件工程相比任何其他工程都更加容易返工，需要软件从业者不断试错、总结、验证，并根据期望重新建立共识。尽快建立原型是一个重要的步骤，有了具体的原型，可以降低项目的风险，可以给客户展示和进行可视化跟踪。往往这个过程是伴随着系统的迭代和演进的。

回到微服务，我们说微服务架构在建立原型上有天然的优势，微服务架构的很多特性能让我们快速落地和逐步地独立完善和迭代项目。

● 微服务架构强调细粒度的服务，在服务规模上尽量精简和务实。

● 微服务架构只做好一件事，没有过多的其他因素干扰，我们可以将注意力集中在完成这件事情上，尽量排除干扰因素。

● 微服务架构提供轻量级的通信集成方式，有利于集成测试和验证结果。

● 微服务架构建立在已有的技术基础之上，能够更加快速地构建、发布和体验应用。

软件的复利效应

=======

在软件工程实践中，在项目的启动或者早期阶段，经常会面临技术方案的选择问题。一些软件工程师会陷入自我保护的状态，认为别人的方案存在缺陷，自己如果重新做会比现有方案做得更好，但其实可能是因为他不了解“每个软件可能都是在某种约束条件下工作的，而且适用于某些特定的场景”。我们把这种现象称为“NIH（NotInvented Here）综合征”。NIH 综合征的结果就是重新发明轮子，患有 NIH 综合征的人相信内部开发更安全、更高效、速度更快、维护成本更低，然而，其实他们并不一定能够使用创新的方案来解决实际的问题。目前，软件正朝着规模化和标准化的方向发展，标准驱动下的软件开发和集成方式，要求你的工作能够集成到标准中，而不是另起炉灶。NIH 综合征的危险之处就是，你的软件、你的服务无法与标准对接，你的系统可能成为一个孤岛系统。例如，在你提供了私有协议的 RPC 方式暴露服务的情况下，你的服务只能生存在自己的闭环体系中，而且基于标准的 HTTP 接口 API 的调用方式很难与你的服务集成。

项目的生命周期受很多因素的影响，预算、人员成本、推广等都会给项目的持续发展带来风险，NIH 综合征会给项目的持续发展带来额外的成本问题，因为你缺少相关人员、资料、生态的支持，而采用标准化的技术可以从互联网中得更多的技术、社区和人员的支持。