先叠一个甲：单体也不是不能用，真的没必要强上微服务搞得一地鸡毛。
1 、微服务本质是一种封装模式
2 、微服务通过通过转移系统复杂度来降低开发过程的系统复杂度
3 、微服务对运维能力有较高的要求
4 、微服务可以支持多语言混合开发
5 、微服务可以支持局部功能动态水平扩展
微服务肯定是有好处的。但是，要不要上微服务架构，并不是取决于你的业务复杂度有多高，你的用户数量有多大。而是取决于你会不会封装，和有没有自动化运维能力。
如果封装稀烂，上微服务的表现就是服务调用链路超长。缺少自动化运维能力，就表现为服务的部署特别费劲，上个线磕磕绊绊的老折腾了。单体巨石照样能够很好地运行。
 |
1
chuck1in 3 天前
是的，就是这样。不知道 up 是 java 吗？
其实 java 并不是只能搞成那种微服务巨型应用，也可以做成小巧的单机模式，同样能维持很大的负载。 另外微服务很多人理解错了，总觉得要弄到很多台服务器上去。特别是很多其他技术栈的同学有误解。 可以看看这个架构： https://github.com/ccmjga/mjga-scaffold/tree/model-first 这也是一种「微服务」或者叫「模型」也行。就是单机的，用起来很简单，什么都有。 |
 |
2
securityCoding 3 天前
我的感触是 90%的业务不需要微服务
|
 |
4
8355 3 天前
很多公司的应用都是单个 ecs 恨不得拉 10 个项目进去平摊服务器成本，这样的公司根本没必要搞微服务。
起码能做到你的流量很大很重要，单机部署高流量应用达到 20 台 ecs 以上且总应用数量超过 30 且有多个语言才有这个必要，不然根本感受不到收益。复杂度没达到多花这个钱一点意义都没有。 现在云服务有各种简便的微服务模式，也不用从头开始搞。。 阿里云 SAE 用的好好的，又简单又好用。。。 |
 |
5
iYume 3 天前
我对微服务的理解就是《简洁架构之道》里说的组件化设计，拆包需要考量与其他服务的依赖与独立性，好处就是封装性、版本管理、依赖管理、升级和回滚方便（每个服务独立数据库）。至于水平拓展，我觉得这是容器化的优点，而不是微服务的优点。
|
Select Language