用户69330831
我用了两三年的微服务了，一般来说不到万不得已不要过早的重构架构，凡事有利就有弊，微服务固然有很多优点，也存在很多缺点！
一开始的系统多半是集成应用，所有业务功能耦合在一个应用里，在单台服务器性能支撑不了的时候，采用nginx负载均衡加多台应用服务器组成的集群来应付，但是业务代码始终耦合在一起，某个业务功能上线带上bug，整个系统都有风险，修复的时候需要撤下整个系统！
然后以webservice为主的SOA架构走上舞台，通过服务化治理，将业务功能进行拆分并单独部署，服务之间通过某种协议进行通信和数据传输，但是SOA架构通常比较笨重，虽然解耦了业务功能，单一服务功能的单一选择，但是SOA的接口暴露协议太过笨重，还遵循ESB企业服务总线，开发难度不低！
SOA虽然已经实现了业务间的解耦，但是粒度较粗，所以更为细粒度的微服务框架开始逐渐流行(以springcloud和dubbo为代表)，让服务实现组件化，围绕着业务细领域进行服务的开发和部署，可以说微服务秉承了SOA的优良特点的同时，拥有着更多特性。
以springcloud为例，通常基于springboot进行服务开发，然后使用服务注册与发现中心eureka，zk等实现服务之间的统一发现和调用，使用分布式配置config将配置文件进行单独的部署，在启动服务的时候从配置中心获取到配置，使用zuul实现网关的动态路由和监控，使用hystrix实现服务熔断，防止服务雪崩带来的影响，使用feign实现客户端的负载均衡，可以说springcloud微服务家族提供了更为完善的组件化开发方式，为微服务的集成开发提供了极大的便利！
微服务很快的吸引了大量的公司加入，因为中大型应用在微服务的架构中有着更加灵活的开发和部署，但是微服务也有着很大的缺点，比如服务之间数据一致性难保证，通信存在隐患，大量微服务容器的管理，运维也是很大的压力！
当然，微服务的东西涉及到的技术比较广，实际情况也比较复杂，只有在实际中不断碰钉子，才能对微服务更加的了解，如果您在微服务处理中，有实际问题，欢迎一起交流，更多的技术分享，敬请关注。。。
