大家应该都维护过
高耦合
臃肿庞大的程式码
牵一发而动全身
于是软件工程大家越来越重视
今年在JCCONF上的议题
不少讲者有提到微服务的概念
可能是Docker的火红造就运行环境的设定方便
DevOps的精神创造高频率deploy的神话
各种框架能够快速搭建APP
微服务在这样的环境下产生
功能拆分出来
工程师能够小组专注在自己的功能上实作与维护
跨平台跨语言各种弹性
重要的是不用再面对糊成一团的大架构
凡事一体两面
增加服务之间之间的沟通成本
API接口的更新容易失去控制
资料的一致性更须完整规划
但比起过去的大型专案
微服务仍然是利大于弊
未来大家都会想改以微服务来改善程式码吗？
微服务会有什么致命的缺点吗？

利大于弊是统计结果, 还是心理结果?

为什么你觉得大架构就会 糊成一团?

钱

频不频繁更新不是重点,重点是没钱我死都不帮客户更新进帐要跟需求相当才是重点

系统的维护会变得更复杂，使用微服务有些基础条件要先具备

从micoservices可以解决的问题当切入点，如果没那问题，就不需要额外搞得特别复杂。但有些问题眼前microservices的确就是适当解。https://goo.gl/RDHGmg 这篇简介地不错

特别擅长抽象归纳和制造概念 XDD

大架构不一定会糊成一团，但微服务肯定不会全部架构糊成一团呀，顶多各自糊自己的小service XD

觉得微妙 整个系统还是要画好各服务的拓朴 定好接口如果原系统有下过这些功夫 那就没有糊成一团问题了吧

做生意还是要看人 技术终究是辅助

标准化降低自由度增进开发速度，产品可能缺乏创意。

由软件的架构转换成系统的架构，难度真的变低了吗？最近用docker建立一间公司ec+erp+crm+iot系统，开发仅仅不到两个月已经使用超过20个container. 以架构过程来说只是换汤不换药，难度还可能变高。然后规划不好一样乱成一团，糟糕的software class interface跟糟糕的service application interface比起来后者还更难重构......但microservice还是比以往较大的service有更多好处，所以我还是会推荐microservice

楼上好像越描越黑

其实我个人认为可以随时将各种service组合成新的解决方案，就蛮值得了。一般大型架构写的好也能做的到，但微服务弹性肯定是较高的。

功能且不论, 但什么时候看过微软的接口更新让程式出问题了? 这会出事单纯就是管规格的人的错吧.