楼主:
chal ( )
2023-11-09 22:16:52微服务似乎可以改善一点这方面的问题
系统开发有点像是公司还很小的时侯
当你公司还很小的时侯
某个职员要当客服 又要兼仓管 又要兼销售
所以这个职员可以拿到各种不同的数据
当公司开始变大以后
就会有财务部 客服部 商品部
每个部门的数据再也不像小公司时可以任意取得
每个部门内部各自处理管理
其他部门不用管另一个部门也不用知道他们怎么管理
部门之间的沟通要透过窗口或部长
当系统一开始小的时候
就像小公司校长兼撞钟
一包系统可以同时去存取会员资料与商品资料与物流资料
当系统变大以后
其实也应该像小公司变大公司那样划分不同部门
把各个不同性质的资料抽出来变成微服务
这样的好处就是减少耦合
服务内部不管如何改变
只要对外保持一致就不用担心
如果有那种万年不用更动的服务
那就让他安静的待在角落 不要管他
新进人员也不用花心力去理解那个服务
每个服务很小
小就代表容易理解也容易测试也容易改动
不同部门的资料互相隔离 也更安全
一间公司变大很自然就会划分成各个部门
一个系统变大非程式人员却不容易理解为什么要拆开成不同包
想像有一间 5000人的大公司
每个人都可以任意去各部门拿资料拿数据
而任何部门有任何变动都要想办法去确定这5000人都确定这个变动
这就是程式的世界
系统写久了 5000支程式是有可能的
任何变动都要确定这5000程式没受影响
那改起来就是灾难
自然而然很不想去乱动
或者动不动就想重写
用公司变大去解释或许可以让人理解
公司变大了要有不同部门
可以把部门的小变动固定在某个部门内
不会去影响全公司
当然微服务要弄起来也要有一些成本
所以小公司才校长兼撞钟
作者:
MoonCode (MoonCode)
2023-11-09 22:52:00别
作者:
tsao1211 (Sunday)
2023-11-09 23:46:00你用过微服务？
作者:
mozume (米虫)
2023-11-10 06:05:00会有原原po问题的千万别用微服务，连单体服务都搞不好的上微服务只会是灾难
作者:
DrTech (竹科管理处网军研发人员)
2023-11-10 08:10:00不管是服务还是微服务，你的概念就是模组化把解偶合，减少每次变更需要处理的工作量而已。 重点是人的头脑有没有这种概念：没有这种工作概念，不管你是用什么服务，微服务，还是把自己搞死。这就是为什么，有些人觉得：怎么可能专案完成越多，事情与压力越多。有些人觉得，专案完成越多，事情越多的差异。不同的人，做事情的观念决定了一切。
微服务我觉得只有server挂掉有差其他还是看开发习惯吧
作者: WTS2accuracy (宝钟海贼団の一味) 2023-11-10 09:39:00
微服务大部分都是拿来嘴砲的 会用的少之又少多的是没多少成效甚至比不拆还惨别网络文章看一看就高潮吹上天 实际没这么简单
推原po，讲得很好感觉很多人只是没遇过微服务>单体的状况或是没在成熟的微服务体系待过而已微服务在处理的并不只是程式的问题但可能大部分台湾公司的业务大小就是不会需要微服务吧
微服务不就是你原本只要管一个服务 拆开之后变成要管10个微服务
作者:
srwhite (鲁蛇阿白)
2023-11-10 11:35:00我们公司拆完之后发现外部耦合变得有点严重XD想改api都不确定会不会哪里有别支呼叫不过应该是可以从文件管理层面解决
作者: tsaigi (菜鸡) 2023-11-10 12:20:00
说微服务是嘴炮的 应该是忘了加”在台湾” 这个条件
作者:
hegemon (hegemon)
2023-11-10 12:22:00楼上, Amazon影音串流那边都写文章说把微服务换回单体反而省很多钱了
微服务用在机台单一方面还可以啦 因为改动不大 通常也只会丢资料收资料
作者:
Litfal (Litfal)
2023-11-10 15:31:00根本问题还是内聚力和粒度阿
作者: WTS2accuracy (宝钟海贼団の一味) 2023-11-10 17:26:00
微服务跟单体是权衡取舍 无脑推的根本实际经验吧*没实际经验
作者:
shvanta (vant)
2023-11-10 17:28:00推
微服务如果乱切或是没有搞懂系统未来的走势很容易陷入微服务架构的缺点，微服务有些优点没被提到，实作的语言执行的系统都不需要考量其他服务。当然在小公司或是一个人负责一堆微服务的时候会觉得用单体的方式开发比较快，比起开API给其他微服务呼叫，单体内call function在开发上快多了
作者: yamagishi (山岸刑务官) 2023-11-10 20:24:00
软件就是会成长，不可能避免的不要乱就像你说的不能每一个人都有相同的存取权限所以才有部门这种东西做为权限的最小单位你后面补充的DDD那些就一种管理方式对于一些team来说合适，有些不合适跟review还有人员教育比起来，更偏重文化的部分你这边的举例可以说是相当不合适
DDD放在这里不会不适合吧？DDD很大部分就是在探讨domain boundary/bounded context的拆分再说它不只是一种管理方式，它是一种软件工程中的设计方式
“任何部门有任何变动都要想办法去确定这5000人都确定这个变动”不用啊, 制造部最大, 他说了算
作者:
brucetu (sec)
2023-11-11 12:51:00感觉你以为划分了部门就不会乱你再去看一次原篇第一段提出的问题，根本不是任何开发方法可以解决的给你一套神级开发方法，你就能一人扛整个公司的全部系统开发加维运吗整篇我只看到纸上谈兵吹微服务好处，无视微服务本身的开发成本，你真的用过？这种吹观念实际上对读者没帮助的文章网络上一堆跟推广企业引入大数据就可以怎样怎样，没什么差别有听过自从引入微服务，公司裁了几个工程师节省成本的？应该都是成本反而更高
作者:
jack0204 (Jarbar王朝)
2023-11-11 14:38:00有哪个开发流程是为了节省成本的?
作者: L90156 (【Ｄ】) 2023-11-11 15:46:00
.......一群井蛙，没实作过微服务的，不懂真的可以闭嘴!!偶然看到这版，进来看一下，思维水准都太低端了...
作者:
alihue (wanda wanda)
2023-11-11 16:35:00楼上不要只会嘴，发一篇有水准的来看看啊
作者: s06yji3 (阿南) 2023-11-11 20:10:00
他一定不会发的啊（摊手）
有人在说Amazon那篇文章，那篇根本上是因为要反复在workflow framework 中不同step 重复存取object storage 的资料，所以可能耗费多余的IO跟cost，但重点还是想清楚step 的切分、工具及情境的使用，并不是说一定monolithic 就一定好。
作者:
hegemon (hegemon)
2023-11-12 13:33:00不管选择走哪条路都要先想清楚需求跟人力呀，不是像很多人那样无脑微服务. 每个场景都有各自适用的方法
作者:
fullout (f)
2023-11-13 22:04:00推概念解说
DDD是切分方式不是管理办法 讲引入微服务成本更高多半是没devops 没自动化后面维运管理爆炸开发流程不为了成本是为了啥? 陨石开发就好啦
作者:
drakd4d (NULL)
2023-11-14 19:19:00微服务大多只是解决政治问题而已成本很高的
作者:
gpctv (gpctv)
2023-11-15 15:02:0077楼，很凶喔！
作者:
MIM23 (HAWK)
2023-11-17 22:10:00微服务后还要用APIM控管API，事情会越来越多