Java开发必读--初识微服务一定要阅读这篇文章

原文转自一线互联网资深架构师，微服务布道师小马哥的原创文章，始发与小马哥公众号。

微服务是什么？

微服务是一种细粒度（Fine-Grain）的SOA

或许在座的高朋了解过其概念。个人认为，与其说微服务是一种技术，不如将其定义为一种架构，而架构则是“技”的实现与“术”的策略相辅相成。“术”的策略需要分析使用场景，进行合理地划分业务边界，实现“业以类聚”，然而“技”的实现则通过特定的技术在实现业务逻辑之时，更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性，达到“技以群分”的目的。

由此而论，我个人偏好将其定义为：“微服务是一种细粒度的SOA”。

这样定义的好处在于，没必要去重复地“抹黑”“单体应用”（Monolithic，也有人翻译成“巨石应用”），缘于SOA技术的衍化过程中早已提及。那么，细粒度更多的体现在“取其精华，去其糟粕”。

SOA又是什么?

SOA = Service-Oriented Architecture

SOA 中文定义是面向服务架构，它并非是今日的重点，请原谅我不能花大篇幅来加以阐述。我用“点到为止”的方式描述SOA具备哪些特征，以及相关的技术。

SOA有什么?

特征

• 面向服务（ Service-Oriented ）松耦合（Loose-Coupling）模块化（Modular）分布式计算（Distributed Computing）平台无关性（Independent Platform）集中管理（Center Government）

技术

• Web Services
• Web Services 技术演进的目的在于解决分布式计算中，统一异构系统的服务调用的通讯协议。前期的Web Services有XML-PRC、WSDL、SOAP等技术，不但解决了Windows平台COM+以及Java 平台RMI无法跨平台的问题，而且使用了可读性强的本文协议替代了复杂的二进制协议，如CORBA技术。现代的WebServices 技术主要代表有REST等。Message Queue
• Message Queue 技术设计的目的主要有两个方面，从架构上来说，消息队列服务帮助系统之间依赖关系解耦；从技术上来看，消息队列为系统提供异步处理的能力，解决了并发同步调用导致资源消耗过集中和过快等问题，将上下游系统的数据结构提供了统一的传输介质。ESB
• ESB 则是 SOA 集大成实现。

SOA不是什么?

SOA ≠ Monolithic

SOA 不但不是Monolithic，而且是要解决Monolithic，Monolithic 个人偏好翻译成“单体应用”，也被翻译成“巨石应用”。

Monolithic是什么?

 

这是我

 

故宫

朋友可能觉得奇怪，故宫与“单体应用”有什么关系？故宫是帝王居住和办公的场所，她象征着“最高权利”和“中央集权”。华夏民族，自秦朝的“三公九卿制”，还是隋朝的“三省六部制”，以及明清的“内阁制度”，无一例外地致力于巩固“中央集权”。

近两千年来，虽然王朝不断更迭，这个制度一直被沿用，并且没有出现大的诟病。可是，1793年，英国勋爵马戛尔尼出使中国，代表英皇为乾隆皇帝祝寿，也负有促成中英通商的使命。虽然当时的中国笼罩在“乾隆盛世”的光环下，不过在马戛尔尼看来中国无论从科技还是社会制度上，均处于相对落后的阶段。《左传》有言：“民之多幸，国之不幸”，当时的大多数国民视英国为“蛮夷”，不与商贸往来。五十年后，中英鸦片战争爆发，1840年，中华帝国第一个不平等条约《南京条约》被迫签订，它不但打击中华名族，而且“打醒”了大和民族。明治维新后的日本，屡屡挑战中国的东亚地位，直到中日甲午战争失利。1895年《马关条约》签订，割台湾，赔巨款。但仍有康有为等不愿放弃，联名千人“公车上书”，认为“中央集权”并不是问题所在。“中央集权”职责臃肿，行政不力，中央政策想要对地方面面俱到是不可能的，无法做到“因地制宜”。

我想说的是，单体应用不正像一个“中央集权”的政府吗？而微服务应用则更像“多权分立”的“自治”政府，各个“自治”政府之间在“联邦”的架构下“分工”和“协作”。

Why？

“学而不思则罔”

为什么要微服务？

• 效率的需要
• 应用进行微服务化后，规模和体积变得更加轻量级，在编译、打包、分发、部署等环节节约了时间，开发上效率提升。质量的需要
• 微服务应用面向持续集成友好，自动化编译、单元和集成测试用例执行和回归，提高应用整体质量。稳定的需要
• 当应用大而全时，往往牵一发而动全身，其中一个服务出现问题，整体受到牵动效应。整体稳定性得不到保证，因此，经过微服务化后，应用由原来的服务内部组装到服务自由组合，一旦关联服务存在问题，整体应用可以选择性地降级或熔断等措施，待问题服务恢复，一切照常执行。运维的需要
• 微服务应用具备自动化编译、打包、分发、部署和运维的能力。传统的应用不但需要开发、还需要测试和运维人员，微服务应用实现后，将理想化的全栈（Full-Stack）工程师变为可能。成长的需要
• 微服务能够更好，更快地适配新技术，比如目前流行的Apache Kafka。而工程人员需要接触新的技术，为未来可能的技术选型做好准备。我的建议在一些不那么重要的微服务应用中，可以尝试一些新的技术，在其提供的功能与实际需要之间，找到一些自己的理解，也是自我成长的需要。

为什么不必微服务？

论语有言：“子绝四：‘毋意、毋必、毋固、毋我’。”，简单地说，不要臆断，不要固执，不要自我感觉良好，也有什么是必定的。那么，在微服务实践过程中，哪些因素可以不必微服务呢？请注意用词，这里说的是“不必”，不是“不要”。

• 场景单一
• 当应用的场景单一时，没有必要非得微服务，因为它本身就是微服务，例如一些静态的通告页面。逻辑简单
• 当应用逻辑简单时，同样也违背了微服务的初衷，因为微服务是为了解决复杂业务逻辑而衍生，因此这种情况下也不必实施微服务。业务渐逝
• 首先，我解释一下“渐逝”，也就是逐渐消逝的意思。当应用所关注的业务趋于消逝状态时，尽管有实施的空间，但无实施的必要。因为这样的应用随时可能不复存在，好比没有必要去对BB机或者短信业务大张旗鼓的重构一般。“老成持重”
• 老成持重的原意是形容人做事情老练和沉稳。这里我引用了这个成语，是为了方便记忆，需要将其拆开，单独解释。
• “老”是指年老的应用，多久算得上年老呢？个人经验，应用服役年龄超过三年以上。
• “成”则表示应用的规模已成形，业务上几乎不再变化，比如通知应用。
• “持”说明应用的场景还将持续较长时间