没有高并发的场景，整微服务、服务发现、集群啥的，是不是有点步子迈太大了？

• 資深大佬 : niubee1

  你问问领导有多少预算要上多少台服务器先

• 主 資深大佬 : darknoll

  @niubee1 不超过 4 台，都是内网用的

• 資深大佬 : anguiao

  这不挺好吗，带薪学习它不香吗？

• 資深大佬 : niubee1

  同意 3 ，老板都不介意给你机会学习了，就别纠结了

• 資深大佬 : lululau

  同意 3 ，公司出钱让你学习不是好事吗

• 資深大佬 : raaaaaar

  如果你是老板，是管理层，你再思考这些问题，如果你就是个打工仔，那你应该高兴。

• 資深大佬 : luzhh

  好事，同意三的说法，不要错过这波机会，公司提供给你试错机会了，好好干，干好了回报很大。

• 資深大佬 : iamppz

  投标的时候这些都是加分项，另外微服务化也有利于以后的平台化转型呀

• 資深大佬 : mooyo

  挺好的啊 做微服务又不麻烦 提前拆分还方便后续的维护升级

• 資深大佬 : dnsaq

  小公司人人都说要比肩 BAT，预算和人手凑桌麻将都凑不齐。

• 資深大佬 : liuzhaowei55

  我来唱个反调吧，如果业务较小且单一，特别是人手还不足，不要把线上服务搞的这么复杂，带薪学习是不错，线上服务容错性低，到头来业务跟不上，这些东西上了也是白上，你根本体会不到它们带来的优势，反而是徒增苦恼。

• 資深大佬 : cnleon

  面向简历编程

• 資深大佬 : idoggy

  搭个 nginx 玩玩算了，4 台服务器想干啥呀

• 資深大佬 : vandort

  同意 11 的说法。你可以先问自己三个问题：
  1 、团队技术积累够不够？
  2 、公司基础设施建设有没有到位？
  3 、出了问题谁负责定位、排障、解决？

  除非你打算半年内跑路，不然研发团队的可持续发展跟个人的技术成长同样重要。团队技术积累不够，基础设施建设不足，都是很要命的事情。比如你做服务拆分，拆成了很多个微服务，但是没有 ELK （或者其他类似东西），没有配置管理，没有链路跟踪，测试也是手动黑盒点点点，有了问题你要怎么去定位呢？开一屏的终端 tail -f 吗？如果客户要求配置额外的安全策略，要逐个配置文件的去改吗？

  考虑另外一个情况，如果为了去贴“集群”的概念，不小心用了 k8s （或者其他类似东西），碰见大坑了要怎么办？外面招不来懂云计算的人，内部的团队又爬不出去。以你们团队领导的风格，是会 997 爆肝刷苦劳、扣发奖金解散团队，还是会重金聘请顾问解决问题，然后公正地复盘问题，亡羊补牢呢？

  另外，其他的研发同事的能力足以上手这些新的技术吗？输出的文档可以帮助阅读的人理解系统吗（真的有文档吗）？测试团队能不能理清服务拆分之后的整体架构？交付团队能不能消化新架构带来的学习成本呢？

  如果领导不参与具体的研发工作，我建议不妨先用自己的能力范围之内的技术完成需求（然后包装一下对外汇报），再一点一点的在自己的舒适区边缘向外试探。进可向先进的、有前景的技术方向演进，退可迅速回滚到你能掌控的版本，降低风险不可控的概率。这样你可以跟公司一起成长，即使想另谋高就，也会更加从容一些。

• 資深大佬 : js8510

  你有多少开发，办多少事。。如果就一个团队，开发多个“微”服务，开发着开发者你就会发现成一个服务了。

  服务架构是人事架构的镜像。

• 資深大佬 : passerbytiny

  服务中心＋配置中心＋网关＋两个服务，加起来内存占用不超过 3G （其中 1.5G 还是额外预留的）。实际上微服务集群比单节点并没需要更多的硬件资源。

• 資深大佬 : securityCoding

  说明你们的领导务虚不务实,尤其是你提到了私有部署到时候会把开发给坑死

• 資深大佬 : securityCoding

  @mooyo 不是每个公司都有强力的基础团队做支撑的.

• 資深大佬 : mooyo

  @securityCoding 这点很同意 得有一个完整的运维团队 or 舍得氪金上公有云才能玩转这一套

• 資深大佬 : akira

  是。
  但是这种机会难得呀。有人给发工资 让你学习，偷着了呗

• 資深大佬 : zengming00

  公司会为此付出惨痛的教训

• 資深大佬 : dream4ever

  11 和 14 一看就是过来人，建议多听听这两位的意见。

• 資深大佬 : bzshow1

  直接用 bilibili 的架构

• 主 資深大佬 : darknoll

  @vandort 其他的研发同事的能力——只会 socket，HTTP 还没怎么用过，web 从没做过

• 資深大佬 : kkbblzq

  看你们公司有没有比较有经验的 devops 团队了。。。这玩意不只对研发有需求，对运维也有需求的，就算上云商也少不了这些的。。

• 資深大佬 : scofieldpeng

  上说什么带薪学习的省省吧,企业要求的是稳定,和 11 ,14 说的,真要学习,自己云上买个主机玩玩,或者家里搞个破烂服务器都能玩,老实说,量没上去,业务没上去,别搞那些虚的,什么微服务,其他我就不说了,同样的东西,你微服务要多少时间?更不要说什么运维之类的成本了,别抱什么侥幸心理不会挂之类的,线上到时候真跪了你难道要给客户说我们上了一个很牛逼的东西,但是这东西我们还是在学习期?

• 資深大佬 : wangxiaoaer

  微服务可以考虑，但别像有些教程那样拆的太细。

  服务发现啥的久别扯淡了，就你那几个服务一眼就看完，人工发现就 OK 了。

  集群无所谓，看情况。

• 資深大佬 : young1lin

  要我，我偷着乐了，我可能年后去一个二线大厂打工还用不到微服务呢。

  带薪学习，先干他个半年。简历上重构原有项目至微服务架构。

  不过，这个看日志有点麻烦，除非你引入 ELK 这种，还有你还要做全链路测试，各种问题。没个半年以上，搞不定的。拆分项目根据业务来拆，不用根据 DDD 来。就 4 台机器，说真的，干不了什么。

  如果你只是要实现功能的话，我劝你还是搞成多模块应用好，把通用模块拆出来（这就是通用域啊），之后再慢慢改成微服务都行。

• 資深大佬 : oneisall8955

  带薪学习？你公司这样的体系怎么感觉会学歪了

• 資深大佬 : KuoYu

  千万不要！血的教训，在一家初创公司刚开始的时候 leader 就提出微服务 集群等，就 4 个人做这些大坑一个接一个，最后交付期拖了又拖，到我离职都没完成。做个人吧，老老实实传统业务做好做精不好吗？

• 資深大佬 : tedzhou1221

  想起一个互金行业的上市公司的后台，看日志也是上终端看，麻烦死了。后来发现是有 ELK 的，然后他们说不会用。。。。

• 資深大佬 : optional

  3 台 k3s，不就啥都有了

• 資深大佬 : atonku

  把现在的代码复制一份，部署上去，告诉老板，微服务做好了

• 資深大佬 : Tarkky

  谁来给扫下忙，微服务到底适用的场景是啥？它的痛点又是啥？谢谢

• 資深大佬 : winglight2016

  个人看来，9 成 9 的软件是不需要微服务架构的，然而就业市场上吃香，lz 不妨抓住机会学习一下。毕竟这么一大坨技术栈，不在实际项目上应用是想象不出来有多么复杂。好在，你不需要严格划分“微”服务，只需要按子系统分一下，然后能够互相调用就好了，毕竟，能够容器化领导就已经直呼专业了。所以，这种项目真正考验你的不是学习能力，而是项目规划能力，加上服务注册 /发现，错误处理，不就是二期需求了吗？再来一些 k8s，热更新、灰度部署啥的，三期就来了。程序员最重要的能力就是给自己安排合适的工作。。。（

• 資深大佬 : luzhh

  微服务没上说的那么恐怖，我当时也是一个人搞微服务项目，一波下来没啥复杂的，但是该有的确实得有，不然那就是挖坑，链路追踪+日志中心得搞好，要不然排查问题特别麻烦。

• 資深大佬 : abcbuzhiming

  @Tarkky 微服务本质是用空间换了复杂度，用体积膨胀，人员膨胀的方式把问题分而化之了。所以如果你的组织度跟不上的话，你解决不了问题，反而问题更多

• 資深大佬 : abcbuzhiming

  @luzhh 链路追踪和日志中心的成本真高，动不动就是几台服务器，或者要上 ELK 做查询。我其实很早就想把自己的服务拆分化，后来一看我才几台服务器啊。我要拆了得上链路中心和日志中心，搞不好在这上面的服务器比我的应用服务器都多，实在是尴尬。

• 資深大佬 : xuanbg

  @abcbuzhiming 1 台 4C16G 就够跑 20 来个服务了。。。微服务不一定要多少台服务器，而是适当拆分服务。拆分服务的好处是能够在局部(单个服务)有效降低业务复杂度，使每个服务都容易维护，且整个系统易于扩展，反正就是加个服务(一只羊是赶，一群羊也是放)。

• 資深大佬 : agagega

  https://ruby-china.org/topics/39735

  巨石架构很香啊

• 資深大佬 : xcstream

  简历上多个可以吹的项目

• 資深大佬 : mtrec

  支持带薪学习 一套下来也不算太复杂 并发不高的话不觉得有什么谷歌解决不了的坑

• 資深大佬 : CantSee

  四台服务器搞微服务吗？服务容错会比较低！不过带薪学习也不错

• 資深大佬 : heart4lor

  集群不一定是高并发场景才适用呀，HA 集群一定程度上也能减少宕机时间，后面业务量上来了直接加实例数也几乎没有技术成本

• 資深大佬 : lewinlan

  我觉得主只是被那些名词唬住了。
  实际上现在这些事情都有完善的框架实现，一套下来并不复杂，一个人撑起一个运维团队也不是不可能。
  性能损耗也没那么夸张，传统行业的自建服务器比云上的共享服务器强太多了。
  不过要注意那些不可预见的坑，如果领导在这方面经验丰富，能解决难题，那下面的人就放心去做就是了。
  但是看主对团队的描述，战斗力很弱的样子……
  所以我猜想你们这个步子的确迈太大了……

• 資深大佬 : MoccaCafe

  同意 11 和 13 ，如果人手不足且时间赶，能不上新技术就不上新技术。按照我以前开发的经验，微服务虽然拆分出来 BIG 更高，但是开发效率降低了，人手不足就算了

• 資深大佬 : luzhh

  @abcbuzhiming 链路追踪没啥成本的，如果存储数据量过大可以设置存储比例。日志中心也不会有啥特别大的成本，无非就是数据存储多久的问题。这些东西听上去很高大上，等你玩过一次就知道其实也没多复杂的。