你们不需要维护企业网站的吗?都这么幸福的吗?为了提高企业形象、给用户增加新鲜感,现在决定给网站改头换面弄个时髦的新样式。几个开发老哥一合计,老网站用了这么多年的 jsp ,咱们是不是也得与时俱进一下,这样万一哪天公司混不下去了也不至于找不到工作不是》
按照目前公司的人员配置,java 这语言是肯定不能换的,不然出问题搞不定大家一窝端。说是做新网站,但一直有需求在提,停下来不改是不可能的,而且老站五六七八年下来,代码结构早就混乱不堪,趁这机会整理一下,但等新站做好,需求早就不知道变了多少版本了,到时候怎么把业务功能同步过去也是个大问题。
因为很难对单体服务划分职责,你可能没在大公司干过,无法理解跨部门、跨公司在超大型项目协作上会遇到什么难题。代码没写几行,整天就在分锅扯头皮了,比菜市场还乱。微服务可以明确划分物理与逻辑边界,减少人员摩擦与管理成本。不过微服务被大量滥用就是另一回事了。一切都是有代价的,微服务的几百字营销用语懒得复述,缺点是性能差、请求时间长,光是链路追踪、海量日志处理、分布式事务就带来无穷隐患,中小厂基本只能买现成服务。
你们不需要维护企业网站的吗?都这么幸福的吗?为了提高企业形象、给用户增加新鲜感,现在决定给网站改头换面弄个时髦的新样式。几个开发老哥一合计,老网站用了这么多年的 jsp ,咱们是不是也得与时俱进一下,这样万一哪天公司混不下去了也不至于找不到工作不是》
按照目前公司的人员配置,java 这语言是肯定不能换的,不然出问题搞不定大家一窝端。说是做新网站,但一直有需求在提,停下来不改是不可能的,而且老站五六七八年下来,代码结构早就混乱不堪,趁这机会整理一下,但等新站做好,需求早就不知道变了多少版本了,到时候怎么把业务功能同步过去也是个大问题。
这时候,如果搜索功能是一个微服务,那是不是需求变更相当于新老网站同时被修改了?如果用户相关的功能同样如此呢?
那订单系统是不是也能通过这种方式受益呢?
原本客户信息的查询只能在网站后台进行,同样的功能在报表系统中需要把代码复制过去
拆分成微服务之后,发现直接调用 api 就好,再也不用两边改代码了,那这是不是优点?
微服务这东西确确实实的解决了需要长期运维项目的维护痛点,如果你觉得它仅仅是个水工作量的玩意那就是你对,层次没到懒得逼逼。
因为很难对单体服务划分职责,你可能没在大公司干过,无法理解跨部门、跨公司在超大型项目协作上会遇到什么难题。代码没写几行,整天就在分锅扯头皮了,比菜市场还乱。微服务可以明确划分物理与逻辑边界,减少人员摩擦与管理成本。不过微服务被大量滥用就是另一回事了。一切都是有代价的,微服务的几百字营销用语懒得复述,缺点是性能差、请求时间长,光是链路追踪、海量日志处理、分布式事务就带来无穷隐患,中小厂基本只能买现成服务。
如果把`微服务`当做一件商品,那许多事情就会有合理的解释。一件商品自然会有适合的用户,但为了赚取更多利润,销售们会把它强硬推销给不适合的用户,包装上好看的外观,精心润笔,夸张地讲述好处,对坏处闭口不谈,与卖保险的没有区别。拿你经常推销的 thinystruct 举例,你认为它适合所有用户吗,假如推广这个框架有利可图,你会做相同的选择吗?