微服务似乎可以改善一点这方面的问题 系统开发有点像是公司还很小的时侯 当你公司还很小的时侯 某个职员要当客服 又要兼仓管 又要兼销售 所以这个职员可以拿到各种不同的数据 当公司开始变大以後 就会有财务部 客服部 商品部 每个部门的数据再也不像小公司时可以任意取得 每个部门内部各自处理管理 其他部门不用管另一个部门也不用知道他们怎麽管理 部门之间的沟通要透过窗口或部长 当系统一开始小的时候 就像小公司校长兼撞钟 一包系统可以同时去存取会员资料与商品资料与物流资料 当系统变大以後 其实也应该像小公司变大公司那样划分不同部门 把各个不同性质的资料抽出来变成微服务 这样的好处就是减少耦合 服务内部不管如何改变 只要对外保持一致就不用担心 如果有那种万年不用更动的服务 那就让他安静的待在角落 不要管他 新进人员也不用花心力去理解那个服务 每个服务很小 小就代表容易理解也容易测试也容易改动 不同部门的资料互相隔离 也更安全 一间公司变大很自然就会划分成各个部门 一个系统变大非程式人员却不容易理解为什麽要拆开成不同包 想像有一间 5000人的大公司 每个人都可以任意去各部门拿资料拿数据 而任何部门有任何变动都要想办法去确定这5000人都确定这个变动 这就是程式的世界 系统写久了 5000支程式是有可能的 任何变动都要确定这5000程式没受影响 那改起来就是灾难 自然而然很不想去乱动 或者动不动就想重写 用公司变大去解释或许可以让人理解 公司变大了要有不同部门 可以把部门的小变动固定在某个部门内 不会去影响全公司 当然微服务要弄起来也要有一些成本 所以小公司才校长兼撞钟 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.170.183.199 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1699539414.A.6D2.html 其实我不是在讲很严格的微服务 微服务如果单论工具的话 其实spirng cloud 出的工具 大概花一点时间学不会太难 工具主要是提供服务之间的沟通与发现 其实就是一些工具设定 但我觉得微服务主要的难点有二个 一个是 服务怎麽切 以及 系统小时候你没机会用微服务 系统大的时成本太大 服务怎麽切有一个作法是DDD 里面又延伸很多术语 DDD是早於微服务的 我也不是全部都懂就不多说了 DDD的副标是 软体核心复杂度的解决方法 我觉得这个才是治本的作法 有很多管理复杂度的作法 比如说去code review 人员教育 都是比较事後 且要公司有余裕的条件下才能做的治标作法 我是觉得程式会乱是出於每个人的思考都是不同的 还有时间压力 所以要靠事後的管理来维持程式的不混乱是很难的 而且成本不小 可以提昇品质 但很难维持 换个主管说不定政策就变了 有的程式是老鸟写的 早已离职 有的程式是菜鸟写的 没办法写的好 时间压力下能动就上线是台湾公司常态 另外程式的写法有百百种 不同的思考也可以完成相同的目的 这也是程式的一种乱 既然乱是改变不了的 那我们就不该想的是让他不乱 而是说乱是一定会乱的 但是控制他的大小 就像你有一个像汽车一样大的毛线球 非常紊乱而且预期汽车毛线球还会一直长大 VS 你有300颗棒球大小的毛线球 而主要核心的毛线球可能十来颗 你控制的不是乱 而是大小 很小的毛线球再怎麽乱你也有能力救 另一个难题就是系统很大时才要改微服务 比如说把会员服务抽出来（不同DB） 你以前捞会员资料是用sql捞 现在要改用token串api接json 那可能5000支程式里有几百支直接间接用到的程式都要改 花半年改了以後 老板问你花半年的时间 系统怎麽没有任何变化 所以我也不是鼓励大老系统去改这个 而是说 作法上概念可以往这方面接近 例如新的业务就不要再加在原来的大老系统上 总之 我不是在讲很严格定义的微服务 而是在说 控制系统越来越大越来越乱的方法 可以有两个维度 一个做法是专注在让它不要乱 另一个是专注在让它不要长大 想办法让他不要长大 小东西就算乱 也乱不到那里去 有天你想好好整理 小东西也是看得到隧道的光亮 控制大小是利用框架与工具 控制品质则是主管与人的思考教育 我是觉得控制大小才是长远的解决之道 但也不是说两者冲突 其实也可以并行 只是在不同时间点的优先顺序不同 综合说一下想法 我没在国外待过所以只是猜想与浅见 国外会流行微服务应该是因为流量 因为微服务被设计成很容易自动扩展 而微服务可以针对核心流量业务去扩展 比如购物网站的流量可能集中在商品服务 那会员服务就没必要用相同的规模去扩展 针对某服务更有效率的扩展 也更省钱 国外有流量的公司自然也有人手去做微服务 就变成正的循环 而台湾2300万人很少有大到需要去做微服务的流量 没有流量也就没钱请够多的IT去搞微服务 之所以没提微服务的其他优点 是因为我也不是在在推微服务 而是在讲越来越大 越来越乱的系统该怎麽处理比较好 程式的很多概念都很像 只是名词不一样 实务作法不一样 但这些不同也是很关键的不同 比如说模组化也是一种拆分重用 但还是不一定能避免混乱 例如新人根本不知道有这个模组 或者老人知道 但不想用这个模组 可能觉得要再加工嫌麻烦之类的 自己直接写方法处理比较快 久而久之类似的模组与方法一堆 也是乱 还是要依靠教育训练与老鸟的品德 但如果从物理上就去阻绝 资料根本不在相同的DB上 这才能更有力量去阻绝混乱 观念会红起来一定有他的道理 如果台湾因为流量没那麽大就舍弃这个观念就有点可惜 如果原生目的不是为了处理流量 未来也不会 那就不用做很严格完整的微服务 但可以去接近 不同业务 不同AP 不同DB 用物理阻绝混乱 在人类的世界 如果一个公司成长到十几人 而不划分部门就容易查觉混乱 权责问题 安全问题 命令传导混乱 自然而然就会把人划分成不同部门工作 但一些没写过程式的主管却不容易理解程式为什麽会乱 你改一个变动 理论上要测过所有的程式 都还不一定能保证没问题 改一个变动要确认5000支程式都没受影响 VS 改一个变动只要确认50支程式没受影响 这是工作心理健康问题 50支程式你会更愿意去把它变得更好 5000支程式你会想说不要乱动 能跑就好 或者你会想说 我搞懂这5000支程式都要半年以後了 不如我们重写某一块比较快 所以保持服务尽量小 那应该是很自然的 权衡取舍 就像小公司校长兼撞钟 大公司有不同部门那样 如果你是永远的小公司 或者你是大公司但业务固定不会扩展 作业流程万年不变 那其实也没必要特意再花时间去划分不同部门 的确是不适用所有的情况 ※ 编辑: chal (1.170.183.199 台湾), 11/11/2023 00:05:00