微服务架构之我感

我个人感觉,新技术会不断的出现,但是在没有这些新技术的年代,一样问题有办法解决,一样有很多成功的产品。有些公司做产品,方向、客户需求、有没有人用都不一定,就开始在技术上追求高大上,什么“分布式、可拓展性、容灾性”,就像“大数据”一样,这东西火爆不是说你在做大数据,你会大数据技术就成功了,数据的价值起了决定性的作用,靠网上抓取数据这样别人也可以轻易获得的数据,准确度、精细度、数量都无法保证,最终难出有价值的产品,往往是自己意淫了一把似乎站在了科技的最前沿,微服务书里也应该说到了,不是所有的场景都适合微服务,微服务等分布式系统带来的架构复杂性没有足够的技术积累,本身就是加大了创业初期的风险,增加成本。本人没有去过大公司,只混迹过小公司,就这些年说,小公司做的东西里能够做出来功能正常、能被客户认真使用的产品或项目的都很少!!

 

更新:2017年07月17日

今天重申一下,微服务对于业务不复杂,不庞杂的系统来说是脱裤子放屁,也许本来就只有一个简单的业务,硬生生的分成碎碎的几块,简直是蛋疼,只有像阿里、腾讯等具有多条产品线,业务交织复杂的情况下才需要服务治理,一共不超过10个Service,玩毛线微服务!那是被微服务玩

更新:2017年07月18日

今天再次有冲动把我的web项目修改为spring boot模式的,但是发现一个问题,就是项目如果配置比较少,用spring boot以及starter是很方便的,如果说需要详细的自定义的话,使用java config 这种方式反而觉得很不方便。

我有大概10个xml配置,是为了修改的时候快速的找到配置的地方,拆开配置可以增加复用性,可以用于其他的项目:

Spring boot 文档中这样介绍它的主要目的:

Our primary goals are:

  • Provide a radically faster and widely accessible getting started experience for all Spring development.
  • Be opinionated out of the box, but get out of the way quickly as requirements start to diverge from the defaults.
  • Provide a range of non-functional features that are common to large classes of projects (e.g. embedded servers, security, metrics, health checks, externalized configuration).
  • Absolutely no code generation and no requirement for XML configuration.

主要解决的是更快的开始用spring干活,大量的starter提供很多常用组件的默认配置,提供内置server,健康监察等,但是如果你的项目不适用默认配置并且配置比较多的话写java代码就不方便了。而且java代码是需要编译的,比如你增加了一个bean,你使用xml可以直接编辑xml就ok了,但如果是java代码你还需要改java代码然后编译。不适合一个传统的spring完整的大项目转为spring boot,适合以微服务这样解决单一问题的小型应用作为一个起点比较好,完全为了使用新技术而使用新技术就没有什么必要性了。还有一个问题就是过小的项目拆分成微服务,你是不是要建立很多的DataSource,每个需要连接数据库的项目都需要创建一个DataSource,每个连接池还会保持至少几个连接,各个Enitty贯穿与多个项目,需要在各个项目之间做转换。说到底,我觉得微服务适合一定规模的系统,太小的系统使用微服务框架配置可能比你的核心业务实现更费时间。

Leave a Comment

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据