04 | 微服务时代：SOA的革命者
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
微服务架构是当前软件架构领域的一场革命，摒弃了SOA的繁琐规范，追求更自由的架构风格。Martin Fowler和James Lewis在2014年的文章中定义了现代微服务的核心特征，包括围绕业务能力构建、分散治理、独立自治的组件、产品化思维、数据去中心化和轻量级通讯机制。微服务架构的核心思想在团队、开发和运维等研发过程中具有重要意义。然而，微服务的自由也带来了一些挑战，如服务间通讯、服务发现等问题需要面对多种解决方案。微服务架构的特征包括服务自治、分散治理、容错性设计、演进式设计和基础设施自动化。这些特征指导着如何应用微服务架构，同时也提醒着我们微服务自由的另一面。微服务架构的崛起标志着一种通过多个小型服务组合构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建，并采用不同的编程语言、数据存储技术和运行在不同进程中。微服务时代中，软件研发本身的复杂度应该说是有所降低，一个简单服务，并不见得就会同时面临分布式中所有的问题，也就没有必要背上SOA那百宝袋般沉重的技术包袱。微服务架构下，我们需要解决什么问题，就引入什么工具；团队熟悉什么技术，就使用什么框架。Spring Cloud这样的胶水式的全家桶工具集，通过一致的接口、声明和配置，进一步屏蔽了源自于具体工具、框架的复杂性，降低了在不同工具、框架之间切换的成本。微服务对架构者来说却是满满的恶意，因为它对架构能力的要求可以说是史无前例。总而言之，微服务时代充满着自由的气息，也充斥着迷茫的选择。软件架构不会止步于自由，微服务仍然不可能是架构探索的终点。
请先领取课程
全部留言(41)
- 最新
- 精选
陈珙这篇文引起了我非常大的共鸣，非常有感触。 我是做.Net实施微服务的时候，当时业界还没有特别成熟的选型与方案，自己在组件、方案之间选型对比、整合花了不少的功夫。架构师是做平衡与取舍，而开发工程师是实施。 微服务的分而治之、化繁为简的思想是减少了业务开发复杂度，但同时引入了很多组件支撑服务，因此加大了技术复杂度。 那么我自己是有几条设计原则： 1.技术服务于架构，架构服务于业务 2.康威定律 3.架构的实施是需要对应开发模式支撑的 总结起来就是，业务规模与团队规模决定了架构的规模，一个增删查改的系统是不需要用微服务架构；使用了前后端分离，那么团队里多数是有前端工程师；由微服务架构拆分引起的量变导致质变，结合devops能更好支持运作。 另外有个小小的建议，第7点，[可靠系统完全可以由会出错的服务来组成]，从可靠性和容错性来看，是不是改成[可靠系统完全可以由容许出错的服务来组成]会更加贴切一点作者回复: 感谢你的意见，你给的建议是更合适的表达。
2020-11-25258
qpzm7903代码之上加一层容器，然后之间再加一层代理。果然软件之间的问题都可以加一层来处理作者回复: Any problem in computer science can be solved by anther layer of indirection
2020-11-2732
tt现状如下。 第一，围绕业务能力构建（Organized around Business Capabilities）。所在团队从负责核心业务起，职责范围不断扩大，一个一个的勾连起来，工作越来越多，配套却没有变化。不知是喜是悲。 第二，分散治理（Decentralized Governance）。必须对服务运行质量负责，只能争取不受外界干预，争取掌控各方权力。 第三，通过服务来实现独立自治的组件（Componentization via Services）。没有服务，一大堆的端到端的小应用。 第四，产品化思维（Products not Projects）。啥都干，开发运维产品设计甚至帮业务定规则。 第五，数据去中心化（Decentralized Data Management）。刚开始有实践。 第六，轻量级通讯机制（Smart Endpoints and Dumb Pipes）。裸通讯，大量使用socket直接通讯，原始。 第七，容错性设计（Design for Failure）。偏向于这样设计，要做到不会变得更差。 第八，演进式设计（Evolutionary Design）。有点项目生命周期很长，不断演进。 第九，基础设施自动化（Infrastructure Automation）。完全没有。 结论:原始时代。作者回复: 很务实很中肯。 看到“结论:原始时代”我有点不厚道地笑了一声：）
2020-11-25623- Mr.Chen其实用不用微服务架构主要取决于业务，撇开业务谈架构都是在耍流氓！我们公司面向企业私有化的项目就没有用微服务，主要是用户的并发量小，考虑到部署和运维的简单，直接上单体架构。
作者回复: 同意
2020-11-2529 
刘智敏“服务会围绕业务能力而非特定的技术标准来构建。”这一点理解起来觉得不是很畅顺，这里的“业务能力”该如何理解？（按康威定理来看，业务和技术能力都是重要因素，这里的业务能力可以理解为团队的业务和技术综合能力，业务层面的需求驱动才是微服务架构的主要动机。）作者回复: 围绕业务能力构建（Organized around Business Capability）是一个比较固定的描述语了，下一节课介绍微服务特征时会提到它。 “围绕业务能力构建”是英文直译，在中文语境中，比较适合的理解是“围绕着一个拥有完整业务能力的团队去构建程序”，潜台词是不要将UI丢给UI团队、数据库丢给DBA团队、应用逻辑丢给业务开发团丢，etc。
2020-12-1634
zhanyd技术永远是为业务服务的，不要为了微服务而微服务。 有些公司的业务明明很简单，没什么并发量，单体系统完全能够满足需求，为了显得高大上，上微服务，分布式，自己给自己找麻烦，实在得不偿失。作者回复: 同意
2020-11-254
Jxin
回答： 1.是基于微服务的（因为用着微服务生态的技术栈） 2.代表目标的那几个特征不符合。 3.适合，因为业务规模够大，且一直在增长和变化。 4.适合，企业有钱有诉求，团队成员有能力，满足基本条件。不过现在负责的这块感觉更像faas服务，也就是基于中台能力层的上层bff层，然后采用faas相类似的技术。 个人疑虑： 1.有些许疑虑，提出来探讨下。理想很丰满，现实很骨感。虽然我们认可小团体的特性团队更适合做开发团队的组成单元，但也存在这种情况：一个域的小团体，需求忙不过来，针对另一个业务域搭建团队又显得成本过大。折中的方案就是搞一个特殊团队，既可以支援超载的小团队，又可以承接不属于任何已有业务域的需求（打杂）。 2.但对于这个特殊的小团体就很尴尬，因为它要跨多个域了解业务（学习压力大），同时做的还是一些鸡毛蒜皮的小功能（价值低）。 3.总觉得只是个打补丁的过度方案，但也没有很好的思路去处理这个问题，不知道周大佬怎么看？这应该也算是微服务架构理念下会碰到的一个现实问题。作者回复: 关于微服务、团队、复杂度等问题的看法，我写过几篇文章，没有放到这个课程里，给出链接供你参考一下：https://icyfenix.cn/methodology/forward-msa/
2020-11-252
Goku关于服务发现有个问题想请教老师：为什么不直接用(LB)负载均衡器的域名作为一个微服务的endpoint。虽然是硬编码，缺少了一些灵活度，但是在大多数情况应该都是够用的而且少了一层依赖(DNS不算的话)。为什么这么多公司都用您提到的那些更复杂的服务发现呢？作者回复: 关于这个问题我写过一篇文章供你参考：https://icyfenix.cn/distribution/connect/service-discovery.html
2020-11-261
snailshen微服务的概念很好，但并不一定适合所有的企业，团队规模决定架构。即时是大公司由于许多历史问题，也难以形成核心业务的微服务化，目前的现状 1.服务间调用依托dubbo,RESTFul service 2.服务发现基本靠团队间沟通 3、服务治理，依托springboot admin,dubbo admin 4、熔断、降级等保障服务可用性的组件基本没有统一 5、devops平台基本没有2020-11-303
丁乐洪小孩子才做选择题，成年人全部都要！2021-01-202