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