这是一个创建于 1772 天前的主题，其中的信息可能已经有所发展或是发生改变。
自学不容易啊.
求非 java 栈的微服务整套解决方案(有代码的).教程和项目都可以. 求推荐.
最好是基于 go/ Python 的.
谢谢啦.
求非 java 栈的微服务整套解决方案(有代码的).教程和项目都可以. 求推荐.
最好是基于 go/ Python 的.
谢谢啦.
第 1 条附言 2020-12-04 12:19:24 +08:00
1. 公司没有微服务项目可以参与.
2. 理论学的再多都是吹牛逼啊, 我想找一个完整的(至少四个微服务吧)项目抄一遍.
拜托大家啦!
2. 理论学的再多都是吹牛逼啊, 我想找一个完整的(至少四个微服务吧)项目抄一遍.
拜托大家啦!
第 2 条附言 2020-12-04 16:16:37 +08:00
可能是标题没起好啊老铁门, 求推荐有源码的项目.
不要教程了.
不要教程了.
 | 1 LieNoWell 2020-12-04 09:56:10 +08:00  1 说得对，我不知道为啥要用微服务，明显是把运维的活转嫁给开发了。 |
 | 2 overthemoon 2020-12-04 09:57:00 +08:00 所谓的微服务就是各种框架往上堆== |
 | 3 stevenkang 2020-12-04 10:00:29 +08:00 1 你想一想，没有微服务的话，跨部门的应用间调用，要怎么做才方便，不可能都在一个项目中写代码吧。 相对应的，如果不需要跨部门调用，仅自己应用调用自己，那就没必要微服务了。 |
 | 4 coderxy 2020-12-04 10:02:31 +08:00 楼上的没用过微服务也别上来就否定啊。 不用微服务，像大一点的项目你就继续单体应用？ 然后十几个人甚至几十个人都在这一个项目里写？ 微服务就是为了解决单体应用的痛点的。 只需学习，网上多看看分享吧。最好是公司有拆分微服务自己参与进去，做一做就知道好处了。 |
 | 5 10Buns 2020-12-04 10:03:10 +08:00 有场景学起来、用起来快得很，没实际需求就是闭门造车 |
 | 6 glfpes 2020-12-04 10:04:21 +08:00 感觉微服务就是一堆有概念的融合 最关键的是服务本体 RPC 和为了方便大家调用和发布 RPC 的服务发现。 然后就是为了保障服务质量的熔断，监控，多 DC 部署等。 |
 | 7 securityCoding 2020-12-04 10:07:50 +08:00 需要你系统的掌握一些理论基础. 《分布式服务框架原理与实践》看看李林锋的书吧 |
 | 8 axex 2020-12-04 10:14:41 +08:00 微服务就是为了将以前的巨型单体应用拆分，开发起来更舒服 |
 | 9 Varobjs 2020-12-04 10:31:08 +08:00 18 年那公司，小体量，php 非要上微服务，然后折腾一年，倒闭了吧 |
 | 10 wangritian 2020-12-04 10:36:10 +08:00 简单理解：内存里的函数调用 => 网络接口调用 按模块分割后，交给不同部门各自更新维护，减少代码冲突和升级失败的地图炮 小项目上微服务有反作用 所有微服务组件都是围绕这件事展开的 |
 | 11 b1ackjack 2020-12-04 10:38:31 +08:00 《微服务设计》这本书一看就明白了 |
 | 12 chendy 2020-12-04 10:40:16 +08:00 没有足够大的项目实践，自学微服务真就挺难的 不大点的项目上微服务，和 hello world 上设计模式一样蛋疼 主要就两方面： 1. 微服务能解决什么好处，能解决什么问题 2. 微服务带来了什么问题，应该如何解决 |
 | 13 kop1989 2020-12-04 10:41:20 +08:00 微服务概念本身其实大家都懂。 关键就是贴近目前大厂生产环境的技术栈量很大。（各种标准、框架、容器、库、工具） 尤其是如果你没有大型团队合作的经验的话，你也很难搞懂这些复杂的框架、标准能为你的团队做出什么贡献。 这个很正常。 所以还是建议先从最简单的入手吧，即便你真的拿到了大厂的真实选型架构，你也很难驾驭和 get 到。 |
 | 14 tairan2006 2020-12-04 10:41:25 +08:00 via Android 自学？你 k8s 也搭不起来啊 |
 | 15 libook 2020-12-04 10:49:49 +08:00 任何技术都是有需求就用，没有需求不要硬用的。 建议先了解一下微服务可以解决哪些问题，有哪些使用的前提条件，如何解决问题；然后根据项目实际情况来决定要不要使用微服务思想。 微服务是一种思想，不是一种特定的代码结构、算法、标准，所以只要应用了微服务的特性来解决微服务擅长解决的问题，就可以称之为微服务。 就好比前端开发，我只想写一个没有任何交互的展示内容的页面，用 Vue 、React 是完全没必要的，至多用原生 JS 加些效果。 |
 | 16 fengpan567 2020-12-04 11:04:28 +08:00 看业务吧，不要为了微服务而微服务，微服务简单的说也就是 RPC 。 |
 | 17 tohuer00 2020-12-04 11:07:06 +08:00 @coderxy 不用微服务这套框架就不能自己拆分项目了么 太多人无脑套用微服务框架这套东西事实上就是徒增了很多没必要的工作。 |
 | 18 aaronly 2020-12-04 11:14:46 +08:00 不太明白微服务和在不在同一个项目里开发有什么关联 |
 | 19 hehe12980 2020-12-04 11:16:43 +08:00 @stevenkang 市面上绝大部分项目 都用不着微服务 但是微服务现在基本是必须的要求 |
 | 20 ericgui 2020-12-04 11:23:08 +08:00 对于微服务，我觉得最基本一个应用场，就是你有多个服务，但共享一套鉴权服务（注册、登录等）。不然你每个服务都写一个注册登录，都保存一份 user table ？ |
 | 21 vertigo 2020-12-04 11:23:43 +08:00 我来举个例子 唐朝唐玄宗时期,边疆总有蛮族骚扰,打仗的痛点在于"决策缓慢","使用统一战法不能适应复杂多变情况",'资源统一中央调集消耗大' 唐玄宗一拍脑袋:"要不我们搞微服务吧",于是有了藩镇和节度使,业务性能巨大提升,因为每个模块决策迅速,战法选型自定. 后来的事情大家都知道了 |
 | 22 VxLzKg4uLbi32w60 2020-12-04 11:28:23 +08:00 .NET CORE 技术栈，微服务用了快一年半了，差了点儿 RPC 通讯，其它都还可以，有兴趣的话，我可以加入到 GIT 上 |
 | 23 woshiaha 2020-12-04 11:28:49 +08:00 5 别上来就追求整套整套。。。先自己写几个微服务用 IP 形式互相调用感受一下 然后搞个注册中心统一用服务名调用 再 然后搭个 docker 环境用镜像形式部署 其后再考虑搭个 k8s 单节点学习服务治理 最后再到 k8s 集群 上来就玩 k8s 你啥原理都不懂环境都能搭一个月 |
 | 24 stramkismet 2020-12-04 11:28:50 +08:00 微服务导致机器成本不断增高....感觉微服务最难的是划分服务的边界 各有利弊吧 |
| 25 stramkismet 2020-12-04 11:29:46 +08:00 @hehe12980 十分赞同，很多应用都没有必要微服务，压根没有那么大的需求，就因为这个概念活了，然后干啥都得微服务。哎 |
 | 26 Dillion 2020-12-04 11:29:56 +08:00 微服务说到底只是一种思想，关键在与服务怎么规划和拆分。 自己设计好服务的拆分，用 REST API，每个服务怎么管理也相对独立。 |
 | 27 lonelymarried 2020-12-04 11:30:25 +08:00 前端接触不到微服务啊 |
 | 28 DoctorCat 2020-12-04 11:31:12 +08:00 不是任何项目都要改造成微服务的，但 SOA 的思路是可以借鉴的。假如，你们小团队内部的小系统才俩人开发，那么让你俩人分工协作很顺畅的架构，便契合康威定律了 |
 | 29 zzzzzzggggggg 2020-12-04 11:38:33 +08:00 不是你不懂，是你没有场景 |
 | 30 40EaE5uJO3Xt1VVa 2020-12-04 11:47:43 +08:00 好多公司的业务前后端不分离也没有性能之忧，硬上微服务就是画蛇添足 |
 | 31 hantsy 2020-12-04 12:11:13 +08:00 学？？？难道使用了一些框架（ Spring Boot，Microprofile, Micronaunt, Helidon, Quarkus 等)你的应用就是微服务架构？ 微服务更多的开发和架构经验上升华，同时面对微服务带来的变化，必须对公司的组织架构和运维全方面改造升级。 只有悟道，没有学道的。古话说的好，功到自然成。 我也了解过国内的一些朋友公司所谓的微服务实践，说白了就是用一个框架，碰瓷微服务这个词，蹭热度而已。 |
| 32 hantsy 2020-12-04 12:11:39 +08:00 @lonelymarried 有 Micro Ｆｒｏｎｔｅｎｄ 在等你。 |
| 33 hantsy 2020-12-04 12:14:50 +08:00 @yanzhiling2001 跟风的结果就是这样的。现在太多的跟风所谓的互联网架构，对于绝大部分中小公司来讲，传统的 ＭＶＣ开发已经足够。 |
 | 34 no1xsyzy 2020-12-04 12:17:31 +08:00 1 承上康威定律，一个人能独自写出符合微服务架构的整套系统，那这个人肯定思考方式、精神状态都不能说稳定。 |
| 35 hantsy 2020-12-04 12:17:31 +08:00 @fengpan567 １５年前 ＲＰＣ 比较流行。 现在除 G 家的 rpc 有点意义（利益于 probuf 协议），其它没必要看。 |
 | 36 ifconfig 2020-12-04 12:20:34 +08:00 1 我们公司用的是 go-kit + gRpc 的方案，然后基于这写了 demo 方便学习和生产化作为基础框架，目前已经加入了 jaeger 链路追踪，有兴趣可以看看代码交流学习呀，https://github.com/ifconfigure/go-kit-grpc-demo/tree/main/gRpc |
 | 37 hujun528 2020-12-04 12:22:40 +08:00 1 疫情期间我用 node.js 写了一套微服务框架，并没有多难 http://www.jianxue.mobi/open/37 |
 | 38 chaleaoch OP |
 | 40 EminemW 2020-12-04 12:50:28 +08:00 via iPhone 微服务 不就是拆项目，然后搞个注册中心，配置中心，服务治理之类的么。 简单的拆项目跟服务发现就能满足更多需求了 |
 | 41 siteshen 2020-12-04 13:13:46 +08:00 项目很容易找，写个博客，多设计些功能，就能整微服务了： 账号系统（注册、登录、权限） 文章系统（读写、转发、搜索） 评论系统（评论文章、用户、动态） 社交系统（关注、订阅、点赞、提醒） 标签系统（ CRUD 、标签继承） |
 | 42 tabris17 2020-12-04 13:18:58 +08:00 |
 | 43 xx6412223 2020-12-04 13:44:50 +08:00 3 大型传统企业的不同企业一般都是不同厂商实施的，之间更是彻彻底底的黑盒。甚至运维可以是不同国家的 team，正因为如此要解决各个系统间的孤岛问题。 例如为了解决继承问题，有企业总线，消息中心, 内外 DNS 。 例如为了解决用户问题，有统一认证中心。 这些都是现有“病”，后“开药”的解决方式。 因为企业不可能单靠自己或者某一个实施商解决自己的全部问题，所以必须要让很多厂商来做。 现在如果把粒度放小，就也有了我们所说微服务的概念：一个团队没有能力完成一整个系统。 而现在更多是为了拆而拆，用实践去套理念，把简单的问题搞复杂。已经有点用烂了。 |
 | 44 annielong 2020-12-04 14:05:33 +08:00 恐怕大多数人做的项目都没有那么大的体量，多加几个 api 就能算是实现微服务了， |
 | 46 nozer 2020-12-04 15:46:26 +08:00 总体思路把控到，然后看看相应的实现组件就行了。 1 、业务分拆为独立的服务。 2 、业务之间的交互（服务之间的交互）。 3 、为了网络容错、发现、追踪问题而扩展的其他东西（异常监控、调用链、预警、熔断之类的，所谓服务治理）。 |
 | 47 tinyRat 2020-12-04 15:53:44 +08:00 没用微服务，可能只是性能问题，堆硬件就可以了。 用上微服务，怎么熔断，怎么监控，怎么发现，怎么容错，怎么通信... |
 | 48 orangeTop 2020-12-04 15:56:21 +08:00 现在我们对已有业务进行拆分，使用微服务开发，但是业务边界就很难确定，开发过程去调用数据也很麻烦 |
 | 49 USAA 2020-12-04 16:01:16 +08:00 大家好欢迎使用魔方大厦 |
 | 50 abersheeran 2020-12-04 16:11:35 +08:00 没具体需求，你很难学会的。微服务体系说简单点就是为了解决远程调用这一个需求衍生出来的。你首先得有需要远程调用不可的业务，然后业务量大了，你就算不懂“微服务”这个词，最终你为了满足需求，还是会搞定一整套体系。 |
 | 51 zorui 2020-12-04 16:15:32 +08:00 service mesh 跨语言 |
 | 52 viWww0vvxmolvY5p 2020-12-04 16:19:21 +08:00 这玩意儿过于复杂，没有项目可以参与=学完就忘==！ |
 | 53 byte10 2020-12-04 16:53:50 +08:00 @tairan2006 哈哈 你这个回答好 |
 | 54 xizismile 2020-12-04 18:03:36 +08:00 via Android 业务架构都是进化而来的 设计上可以先来单体服务，后续看业务迭代变化再具体决定是否要拆分，是否要上微服务那一套 不明白为啥楼上一群人抓着一个思想去喷（或许你们喷的只是自己公司用的太差劲儿了，项目简单还非要整微服务） |
 | 55 lululau 2020-12-04 18:19:08 +08:00 Java 没有微服务，把 spring / DB 框架加上一个 Hello world，jar 包就得几十兆 |
 | 57 dadaslele 2020-12-04 18:36:02 +08:00 |
 | 58 threeEggs123 2020-12-04 20:26:56 +08:00 via Android 楼主可以尝试试用一下云厂商的一些组件，帮你一些微服务的功能。比如 ELB 和 ECS 帮你搞定负载均衡和服务发现。只后用到的监控，溯源什么的，慢慢在加。 |
 | 59 d5 2020-12-04 20:51:31 +08:00 顺口问一下，，，明明有 HTTP 接口，非得打包成镜像，从 jenkins 里调度 k8s 资源起一个临时 pod 来完成 pod 内 cli 工具的调用，这个算不算为了微服务而微服务 /狗头 |
 | 60 firefox12 2020-12-04 21:41:19 +08:00 一个人开发一个项目 你写在一个文件里都可以 1000 个人同时开发一个项目呢？ 当然微服务是由代价的。如果项目很小，这代价可能就太大了。 |
 | 62 xcstream 2020-12-05 02:43:07 +08:00 500 人开发的话就有优势了大概 |
 | 64 yalin 2020-12-05 06:59:17 +08:00 康威法则了解一下 |
 | 65 loading 2020-12-05 08:37:40 +08:00 via Android 就是能独立的无状态小功能，是为了以后伸缩的。 |
 | 66 leafre 2020-12-05 09:13:16 +08:00 1 不会有企业把自己微服务开源 |
 | 67 wc951 2020-12-05 10:06:13 +08:00 via Android 先从 10 几年前的 soa 思想开始理解，你就知道为什么要做服务化这件事了 |
| 68 no1xsyzy 2020-12-05 15:58:24 +08:00 @ericgui SSO 也不一定是微服务，不如说微服务反而麻烦，每个网站都得重新输入一遍用户名密码，不能把登录状态迁移过去。 |
| 69 no1xsyzy 2020-12-05 16:08:48 +08:00 顺便，业务简单却可以正常运用微服务、能够利用到微服务的优势的，想了想就是 Twitter Reddit 这种允许多数不确定公众发布各种内容的地方。 |
 | 70 fumeboy 2020-12-05 17:53:58 +08:00 https://github.com/fumeboy/pome 这是我写的微服务框架 |
 | 71 chaleaochexist 2023-02-15 00:46:09 +08:00 经过两年时间 终于大致入门了. |
 | 72 dandankele 2024-06-27 14:14:26 +08:00 @stevenkang 不好意思挖个坟。。做微服务反而方便跨部门的应用间调用吗？我现在的问题是，这个微服务架构下，不同部门、企业之间如何调用？是不是需要大家有一个统一的标准和要求？也是通过注册到服务中心进行服务发现吗？还是说每个部门暴露出特定的 endpoint 给其他部门调用？ |
Select Language