search

fenixsoft / awesome-fenix

讨论如何构建一套可靠的大型分布式系统
https://icyfenix.cn
8.55k stars 995 forks source link

「Comment」https://icyfenix.cn/architecture/architect-history/microservices.html #127

Open fenixsoft opened 4 years ago

fenixsoft commented 4 years ago

https://icyfenix.cn/architecture/architect-history/microservices.html

xiaoming688 commented 4 years ago

成年人全都要

huangyongliang commented 3 years ago

不仅增加了架构者的要求，同时也增加了“螺丝钉”升级的难度。

holiday12138 commented 3 years ago

自由的气息

ralphhuang commented 2 years ago

@xiaoming688 成年人全都要

绿帽好拼

yywing commented 2 years ago

技术架构者的第一职责就是做决策权衡，有利有弊才需要决策，有取有舍才需要权衡，如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中利弊，恐怕也就无可避免地陷入选择困难症的困境之中。

wangquan86 commented 2 years ago

微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。 这句话总结到位！

qlzx commented 2 years ago

微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。这个写的太好了吧，深有体会呀！

cooljacket commented 2 years ago

如果是一些基础服务，比如用户账号信息查询、商户账号信息查询，这类应该是期望永久存在的？

一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生。假如系统中出现不可更改、无可替代的服务，这并不能说明这个服务是多么的优秀、多么的重要

ZGarry commented 2 years ago

阿里的中间件也因微服务而起，中间件带来巨大好处的同时，也带来巨大的依赖痛苦

zzjcy commented 2 years ago

@qlzx 微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。这个写的太好了吧，深有体会呀！

都是这么过来的呀。。。。贼惨，又迷茫 又向往。。。。

prchann commented 2 years ago

发展历史：

  1. 起初，微服务是作为 SOA 的一种补救方案被提出的；该阶段的微服务并不起眼；
  2. 2012-2014 年，开始有人独立定义微服务（抛开 SOA）。

《Microservices: A Definition of This New Architectural Term》列举了微服务的九个核心的业务与技术特征：

  1. 围绕业务能力构建：强调技术架构为业务服务，与业务发展阶段匹配；
  2. 分散治理：允许技术异构。对应团队为其服务的质量负责，同时允许该团队根据自身情况选择语言/框架等异构技术；
  3. 通过服务来实现独立自治的组件：“服务”而非“组件/类库”，因前者隔离和自治能力好；
  4. 产品化思维：把“服务”看成“产品”，关注服务的整个生命周期；
  5. 数据去中心化：不同服务关注同个数据的重点/视角不同，使用统一的数据容易耦合或相互限制；
  6. 强终端弱管道：管道指通信机制；管道提供基本的通信机制即可，特殊的能力需求由终端/业务服务定制化解决；
  7. 容错性设计：承认“出错无法避免”，做好自动化备案机制（健康检查、熔断、隔离、自动恢复等）；
  8. 演进式设计：无永生，承认会报废淘汰；做好生命周期管理，各自独立、自治，能更好地反脆弱；
  9. 基础设施自动化：更多的服务，更频繁的构建、发布、运维；用 CI、CD 等自动化来支持。

微服务 VS SOA：

微服务丢掉了 SOA 的强标准，换来了自由。自由的代价是工程师需根据业务情况选择适合的技术，过程中会犯错。微服务带来自由，也带来迷茫。 微服务只是一种思想，它丢掉了 SOA 的包袱，却没带来什么具体的东西。RPC 等分布式的问题重新出现，交由社区解决；一时间，百花齐放，百家争鸣。

有利弊才要权衡，有取舍才要决策。

联想：全家桶式框架 (Spring Cloud) VS 无主见框架 (Koa.js)。

junminZ commented 2 years ago

@perrychann 发展历史：

  1. 起初，微服务是作为 SOA 的一种补救方案被提出的；该阶段的微服务并不起眼；
  2. 2012-2014 年，开始有人独立定义微服务（抛开 SOA）。

《Microservices: A Definition of This New Architectural Term》列举了微服务的九个核心的业务与技术特征：

  1. 围绕业务能力构建：强调技术架构为业务服务，与业务发展阶段匹配；
  2. 分散治理：允许技术异构。对应团队为其服务的质量负责，同时允许该团队根据自身情况选择语言/框架等异构技术；
  3. 通过服务来实现独立自治的组件：“服务”而非“组件/类库”，因前者隔离和自治能力好；
  4. 产品化思维：把“服务”看成“产品”，关注服务的整个生命周期；
  5. 数据去中心化：不同服务关注同个数据的重点/视角不同，使用统一的数据容易耦合或相互限制；
  6. 强终端弱管道：管道指通信机制；管道提供基本的通信机制即可，特殊的能力需求由终端/业务服务定制化解决；
  7. 容错性设计：承认“出错无法避免”，做好自动化备案机制（健康检查、熔断、隔离、自动恢复等）；
  8. 演进式设计：无永生，承认会报废淘汰；做好生命周期管理，各自独立、自治，能更好地反脆弱；
  9. 基础设施自动化：更多的服务，更频繁的构建、发布、运维；用 CI、CD 等自动化来支持。

微服务 VS SOA：

  • 相同：面向服务；
  • 不同：强约束 VS 软指导；强一致 VS 自由；规范标准 VS实践标准。

微服务丢掉了 SOA 的强标准，换来了自由。自由的代价是工程师需根据业务情况选择适合的技术，过程中会犯错。微服务带来自由，也带来迷茫。 微服务只是一种思想，它丢掉了 SOA 的包袱，却没带来什么具体的东西。RPC 等分布式的问题重新出现，交由社区解决；一时间，百花齐放，百家争鸣。

有利弊才要权衡，有取舍才要决策。

联想：全家桶式框架 (Spring Cloud) VS 无主见框架 (Koa.js)。

课代表👍🏻

iocyho commented 1 year ago

@cooljacket 如果是一些基础服务，比如用户账号信息查询、商户账号信息查询，这类应该是期望永久存在的？

一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生。假如系统中出现不可更改、无可替代的服务，这并不能说明这个服务是多么的优秀、多么的重要

“账号信息查询”、“商户信息查询”等等都是功能性需求，不是服务。同一个功能可以有不同的实现方案，实现方案对应的才是服务。账号查询功能必不可少，不代表账户查询服务不可更改，随着业务和技术的发展，完全有可能使用新的技术开发新的服务重新实现这个功能。

JesseMccree008 commented 1 year ago

我不再害怕生病，我也一定会生病，但我完全可以自愈

yabocui commented 1 year ago

总结：和SOA比起来微服务非常的灵活，没有复杂的标准，但是对于架构者来说，将架构能力要求提升到了史无前例的程度，架构者需要做权衡，做取舍。微服务有以下特点： 1、围绕业务能力构建，有什么样的规模、结构、能力的团队就会产生什么样规模、结构、能力的架构。 2、分散治理：各个团队负责自己的服务。 3、通过服务实现独立自治的组件。 4、产品化思维：产品不但迭代 4、数据去中心化：数据不在保存在一起 5、强终端弱管道：通过restfule实现通信 6、容错性设计：正视服务总会出错，做好服务的检测、熔断、恢复和重新联通。 7、渐进式设计：承认服务会被淘汰 8、基础设施自动化

williamcai663 commented 1 year ago

把微服务写的生动形象