微服务太难了, 学不会…

• 資深大佬 : MrSheng

  说得对，我不知道为啥要用微服务，明显是把运维的活转嫁给开发了。

• 資深大佬 : overthemoon

  所谓的微服务就是各种框架往上堆==

• 資深大佬 : stevenkang

  你想一想，没有微服务的话，跨部门的应用间调用，要怎么做才方便，不可能都在一个项目中写代码吧。

  相对应的，如果不需要跨部门调用，仅自己应用调用自己，那就没必要微服务了。

• 資深大佬 : coderxy

  上的没用过微服务也别上来就否定啊。 不用微服务，像大一点的项目你就继续单体应用？ 然后十几个人甚至几十个人都在这一个项目里写？ 微服务就是为了解决单体应用的痛点的。 只需学习，网上多看看分享吧。最好是公司有拆分微服务自己参与进去，做一做就知道好处了。

• 資深大佬 : 10Buns

  有场景学起来、用起来快得很，没实际需求就是闭门造车

• 資深大佬 : glfpes

  感觉微服务就是一堆已有概念的融合

  最关键的是服务本体 RPC 和为了方便大家调用和发布 RPC 的服务发现。
  然后就是为了保障服务质量的熔断，监控，多 DC 部署等。

• 資深大佬 : securityCoding

  需要你系统的掌握一些理论基础.
  《分布式服务框架原理与实践》看看李林锋的书吧

• 資深大佬 : axex

  微服务就是为了将以前的巨型单体应用拆分，开发起来更舒服

• 資深大佬 : Varobjs

  18 年那公司，小体量，php
  非要上微服务，然后折腾一年，倒闭了吧

• 資深大佬 : wangritian

  简单理解：内存里的函数调用 => 网络接口调用
  按模块分割后，交给不同部门各自更新维护，减少代码冲突和升级失败的地图炮
  小项目上微服务有反作用
  所有微服务组件都是围绕这件事展开的

• 資深大佬 : b1ackjack

  《微服务设计》这本书一看就明白了

• 資深大佬 : chendy

  没有足够大的项目实践，自学微服务真就挺难的
  不大点的项目上微服务，和 hello world 上设计模式一样蛋疼
  主要就两方面：
  1. 微服务能解决什么好处，能解决什么问题
  2. 微服务带来了什么问题，应该如何解决

• 資深大佬 : kop1989

  微服务概念本身其实大家都懂。
  关键就是贴近目前大厂生产环境的技术栈量很大。（各种标准、框架、容器、库、工具）

  尤其是如果你没有大型团队合作的经验的话，你也很难搞懂这些复杂的框架、标准能为你的团队做出什么贡献。
  这个很正常。

  所以还是建议先从最简单的入手吧，即便你真的拿到了大厂的真实选型架构，你也很难驾驭和 get 到。

• 資深大佬 : tairan2006

  自学？你 k8s 也搭不起来啊

• 資深大佬 : libook

  任何技术都是有需求就用，没有需求不要硬用的。

  建议先了解一下微服务可以解决哪些问题，有哪些使用的前提条件，如何解决问题；然后根据项目实际情况来决定要不要使用微服务思想。

  微服务是一种思想，不是一种特定的代码结构、算法、标准，所以只要应用了微服务的特性来解决微服务擅长解决的问题，就可以称之为微服务。

  就好比前端开发，我只想写一个没有任何交互的展示内容的页面，用 Vue 、React 是完全没必要的，至多用原生 JS 加些效果。

• 資深大佬 : fengpan567

  看业务吧，不要为了微服务而微服务，微服务简单的说也就是 RPC 。

• 資深大佬 : tohuer00

  @coderxy 不用微服务这套框架就不能自己拆分项目了么
  太多人无脑套用微服务框架这套东西事实上就是徒增了很多没必要的工作。

• 資深大佬 : aaronly

  不太明白微服务和在不在同一个项目里开发有什么关联

• 資深大佬 : hehe12980

  @stevenkang 市面上绝大部分项目 都用不着微服务 但是微服务现在基本是必须的要求

• 資深大佬 : ericgui

  对于微服务，我觉得最基本一个应用场，就是你有多个服务，但共享一套鉴权服务（注册、登录等）。不然你每个服务都写一个注册登录，都保存一份 user table ？

• 資深大佬 : vertigo

  我来举个例子

  唐朝唐玄宗时期,边疆总有蛮族骚扰,打仗的痛点在于”决策缓慢”,”使用统一战法不能适应复杂多变情况”,’资源统一中央调集消耗大’

  唐玄宗一拍脑袋:”要不我们搞微服务吧”,于是有了藩镇和节度使,业务性能巨大提升,因为每个模块决策迅速,战法选型自定.

  后来的事情大家都知道了

• 資深大佬 : a194259440

  .NET CORE 技术栈，微服务用了快一年半了，差了点儿 RPC 通讯，其它都还可以，有兴趣的话，我可以加入到 GIT 上

• 資深大佬 : woshiaha

  别上来就追求整套整套。。。先自己写几个微服务用 IP 形式互相调用感受一下 然后搞个注册中心统一用服务名调用 再 然后搭个 docker 环境用镜像形式部署 其后再考虑搭个 k8s 单节点学习服务治理 最后再到 k8s 集群 上来就玩 k8s 你啥原理都不懂环境都能搭一个月

• 資深大佬 : stramkismet

  微服务导致机器成本不断增高….感觉微服务最难的是划分服务的边界
  各有利弊吧

• 資深大佬 : stramkismet

  @hehe12980 十分赞同，很多应用都没有必要微服务，压根没有那么大的需求，就因为这个概念活了，然后干啥都得微服务。哎

• 資深大佬 : Dillion

  微服务说到底只是一种思想，关键在与服务怎么规划和拆分。

  自己设计好服务的拆分，用 REST API，每个服务怎么管理也相对独立。

• 資深大佬 : lonelymarried

  前端接触不到微服务啊

• 資深大佬 : DoctorCat

  不是任何项目都要改造成微服务的，但 SOA 的思路是可以借鉴的。假如，你们小团队内部的小系统才俩人开发，那么让你俩人分工协作很顺畅的架构，便契合康威定律了

• 資深大佬 : zzzzzzggggggg

  不是你不懂，是你没有场景

• 資深大佬 : yanzhiling2001

  好多公司的业务前后端不分离也没有性能之忧，硬上微服务就是画蛇添足

• 資深大佬 : hantsy

  学？？？难道使用了一些框架（ Spring Boot，Microprofile, Micronaunt, Helidon, Quarkus 等)你的应用就是微服务架构？

  微服务更多的开发和架构经验上升华，同时面对微服务带来的变化，必须对公司的组织架构和运维全方面改造升级。

  只有悟道，没有学道的。古话说的好，功到自然成。

  我也了解过国内的一些朋友公司所谓的微服务实践，说白了就是用一个框架，碰瓷微服务这个词，蹭热度而已。

• 資深大佬 : hantsy

  @lonelymarried 有 Micro Ｆｒｏｎｔｅｎｄ 在等你。

• 資深大佬 : hantsy

  @yanzhiling2001 跟风的结果就是这样的。现在太多的跟风所谓的互联网架构，对于绝大部分中小公司来讲，传统的 ＭＶＣ开发已经足够。
• 資深大佬 : no1xsyzy

  承上康威定律，一个人能独自写出符合微服务架构的整套系统，那这个人肯定思考方式、精神状态都不能说稳定。

• 資深大佬 : hantsy

  @fengpan567 １５年前 ＲＰＣ 比较流行。
  现在除 G 家的 rpc 有点意义（利益于 probuf 协议），其它没必要看。

• 資深大佬 : ifconfig

  我们公司用的是 go-kit + gRpc 的方案，然后基于这写了 demo 方便学习和生产化作为基础框架，目前已经加入了 jaeger 链路追踪，有兴趣可以看看代码交流学习呀，https://github.com/ifconfigure/go-kit-grpc-demo/tree/main/gRpc

• 資深大佬 : hujun528

  疫情期间我用 node.js 写了一套微服务框架，并没有多难
  http://www.jianxue.mobi/open/37

• 主 資深大佬 : chaleaoch

  @hujun528
  @ifconfig
  36 37 了 终于有回答问题的了. 前面的 v 友们 我只能谢谢顶贴+送铜板了.

• 資深大佬 : renmu123

  @vertigo 你这个例子的主角是大唐，但如果是夜郎就只能自大而亡了

• 資深大佬 : EminemW

  微服务 不就是拆项目，然后搞个注册中心，配置中心，服务治理之类的么。 简单的拆项目跟服务发现就能满足更多需求了

• 資深大佬 : siteshen

  项目很容易找，写个博客，多设计些功能，就能整微服务了：
  账号系统（注册、登录、权限）
  文章系统（读写、转发、搜索）
  评论系统（评论文章、用户、动态）
  社交系统（关注、订阅、点赞、提醒）
  标签系统（ CRUD 、标签继承）

• 資深大佬 : tabris17

  Nameko https://nameko.readthedocs.io/en/stable/

• 資深大佬 : xx6412223

  大型传统企业的不同企业一般都是不同厂商实施的，之间更是彻彻底底的黑盒。甚至运维可以是不同国家的 team，正因为如此要解决各个系统间的孤岛问题。
  例如为了解决继承问题，有企业总线，消息中心, 内外 DNS 。
  例如为了解决用户问题，有统一认证中心。
  这些都是现有“病”，后“开药”的解决方式。

  因为企业不可能单靠自己或者某一个实施商解决自己的全部问题，所以必须要让很多厂商来做。
  现在如果把粒度放小，就也有了我们所说微服务的概念：一个团队没有能力完成一整个系统。

  而现在更多是为了拆而拆，用实践去套理念，把简单的问题搞复杂。已经有点用烂了。

• 資深大佬 : annielong

  恐怕大多数人做的项目都没有那么大的体量，多加几个 api 就能算是实现微服务了，

• 資深大佬 : bsg1992

  @coderxy 为啥单体应用就非得 在一个项目里写？
  可以按照模块拆分 有不同的人进行开发和维护啊。

• 資深大佬 : nozer

  总体思路把控到，然后看看相应的实现组件就行了。
  1 、业务分拆为独立的服务。
  2 、业务之间的交互（服务之间的交互）。
  3 、为了网络容错、发现、追踪问题而扩展的其他东西（异常监控、调用链、预警、熔断之类的，所谓服务治理）。

• 資深大佬 : tinyRat

  没用微服务，可能只是性能问题，堆硬件就可以了。
  用上微服务，怎么熔断，怎么监控，怎么发现，怎么容错，怎么通信…

• 資深大佬 : orangeTop

  现在我们对已有业务进行拆分，使用微服务开发，但是业务边界就很难确定，开发过程去调用数据也很麻烦

• 資深大佬 : USAA

  大家好欢迎使用魔方大厦

• 資深大佬 : abersheeran

  没具体需求，你很难学会的。微服务体系说简单点就是为了解决远程调用这一个需求衍生出来的。你首先得有需要远程调用不可的业务，然后业务量大了，你就算不懂“微服务”这个词，最终你为了满足需求，还是会搞定一整套体系。

• 資深大佬 : zorui

  service mesh 跨语言

• 資深大佬 : mway

  这玩意儿过于复杂，没有项目可以参与=学完就忘==！

• 資深大佬 : byte10

  @tairan2006 哈哈 你这个回答好

• 資深大佬 : xizismile

  业务架构都是进化而来的

  设计上可以先来单体服务，后续看业务迭代变化再具体决定是否要拆分，是否要上微服务那一套

  不明白为啥上一群人抓着一个思想去喷（或许你们喷的只是自己公司用的太差劲儿了，项目简单还非要整微服务）

• 資深大佬 : lululau

  Java 没有微服务，把 spring / DB 框架加上一个 Hello world，jar 包就得几十兆

• 資深大佬 : zoharSoul

  @bsg1992 #45
  那你项目之间怎么互相调用呢?
  你调用不就是微服务了…

• 資深大佬 : dadaslele

  https://github.com/apache/dubbo-go

• 資深大佬 : threeEggs123

  主可以尝试试用一下云厂商的一些组件，帮你一些微服务的功能。比如 ELB 和 ECS 帮你搞定负载均衡和服务发现。只后用到的监控，溯源什么的，慢慢在加。

• 資深大佬 : d5

  顺口问一下，，，明明有 HTTP 接口，非得打包成镜像，从 jenkins 里调度 k8s 资源起一个临时 pod 来完成 pod 内 cli 工具的调用，这个算不算为了微服务而微服务 /狗头

• 資深大佬 : firefox12

  一个人开发一个项目 你写在一个文件里都可以

  1000 个人同时开发一个项目呢？ 当然微服务是由代价的。如果项目很小，这代价可能就太大了。

• 資深大佬 : vertigo

  @renmu123 大哥,唐玄宗后面就是安史之乱啊,我的意思是就算牛逼如大唐,搞微服务也只能带来混乱

• 資深大佬 : xcstream

  500 人开发的话就有优势了大概

• 資深大佬 : en20

  @vertigo 最后微服务也藩镇割据安史之乱，公司倒闭

• 資深大佬 : yalin

  康威法则了解一下

• 資深大佬 : loading

  就是能独立的无状态小功能，是为了以后伸缩用的。

• 資深大佬 : leafre

  不会有企业把自己微服务开源

• 資深大佬 : wc951

  先从 10 几年前的 soa 思想开始理解，你就知道为什么要做服务化这件事了

• 資深大佬 : no1xsyzy

  @ericgui SSO 也不一定是微服务，不如说微服务反而麻烦，每个网站都得重新输入一遍用户名密码，不能把登录状态迁移过去。

• 資深大佬 : no1xsyzy

  顺便，业务简单却可以正常运用微服务、能够利用到微服务的优势的，想了想就是 Twitter Reddit 这种允许多数不确定公众发布各种内容的地方。

• 資深大佬 : fumeboy

  https://github.com/fumeboy/pome 这是我写的微服务框架