- 主题:微服务带来了新的问题
如果部署自动化了，监控自动化了，运维只是维护这些平台，那就不是运维干啊。
部署变成开发自己主导，运维只是给你搭台子，自己的业务自己管，运维才不会关心你多少个进程。
如果仅仅是微服务了，结果运维的工作增加十几倍，你是运维你乐意么。
【 在 guestking (无) 的大作中提到: 】
: 不管是什么部署方案，最终不都得运维么
: 是嫌部署单元太多运维起来麻烦？
--
FROM 221.220.225.*
gradle 引用。。主项目编译的时候也自动编译了啊。
【 在 guestking (无) 的大作中提到: 】
: 和微服务关系不大
: 看上去比直接依赖jar包麻烦
: 还得自己编译
: ...................
--
FROM 110.81.42.*
这种一千万的标，肯定是带全套运维工具的，或者对接到已有的运维工具上面
【 在 sayinger (言者) 的大作中提到: 】
: 如果部署自动化了，监控自动化了，运维只是维护这些平台，那就不是运维干啊。
: 部署变成开发自己主导，运维只是给你搭台子，自己的业务自己管，运维才不会关心你多少个进程。
: 如果仅仅是微服务了，结果运维的工作增加十几倍，你是运维你乐意么。
: ...................
--
FROM 180.167.95.*
所以我就好奇
为什么不直接引用jar就好，还要自己编译一下
如果子项目多的话，编译一遍岂不是要很久？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: gradle 引用。。主项目编译的时候也自动编译了啊。
--
FROM 180.167.95.*
因为 jar 包里面不能包含 gradle 脚本和各种配置文件啊。
比如我们专门有个 conf 目录，配置文件都写里面了。布署的时候一起放到 docker 映像里面。
【 在 guestking (无) 的大作中提到: 】
: 所以我就好奇
: 为什么不直接引用jar就好，还要自己编译一下
: 如果子项目多的话，编译一遍岂不是要很久？
: ...................
--
FROM 110.81.42.*
那不就还是maven么
【 在 hgoldfish (老鱼) 的大作中提到: 】
: gradle 引用。。主项目编译的时候也自动编译了啊。
--
FROM 103.107.216.233
对啊。。对于中小型不超过三十万行的项目，我觉得只要在 maven/gradle 这些传统工具的基础上稍做改进就足够了。
【 在 PaoloMaldini (solo con te) 的大作中提到: 】
: 那不就还是maven么
--
修改:hgoldfish FROM 110.81.42.*
FROM 110.81.42.*
然后几百人的公司，搞一个中间件团队，爽的要死
【 在 hgoldfish 的大作中提到: 】
: 微服务是为了解决什么问题呢？
: 1. 首先是复用代码和业务。类似于 jar 包，但是又比 jar 包更独立
: 同样的 git 子仓库，也是实现复用的一种办法。确实不包含运维规则，但是很方便参与修改代码。
: ...................
--
FROM 124.64.17.*
互联网搞微服务是解决高并发和研发协作效率。
私有化部署的业务没有高并发的话，悠着点
- 来自 水木社区APP v3.4.4
【 在 oldwatch 的大作中提到: 】
其实我一直觉得微服务的重点应该是你说的那堆”其他“
前面其实就是传统的模块化/分布式
- 来自 水木社区APP v3.4.4
--
FROM 61.148.245.*
只搞微服务，不搞配套的基础设施，那就是耍流氓，自己耍自己
- 来自 水木社区APP v3.4.4
【 在 sayinger 的大作中提到: 】
如果部署自动化了，监控自动化了，运维只是维护这些平台，那就不是运维干啊。
部署变成开发自己主导，运维只是给你搭台子，自
- 来自 水木社区APP v3.4.4
--
FROM 61.148.245.*