微服务的基本概念

所谓微服务，最直白的字面理解，就是小规模的服务。其实，微服务是一种架构设计理念，它是对SOA的一种改进。它把原来大的集成服务拆分成若干个独立的小的服务。服务和服务之间通过调度和协作完成集成服务所完成的业务。在Java中，使用SpringCloud完成整个微服务架构。

 

微服务的优缺点

优点：

• 利于整个服务的横向扩展。可以更加细粒度的扩展某些微服务，资源可以得到最大化的利用；
• 由于微服务间的解耦，可以只改动或升级某些微服务，升级维护成本大大降低；
• 微服务的各个开发团队，可以更加专注于自身领域的业务，提高了开发效率；

缺点：

• 需要解决数据库分布式事务难题，增加了开发难度
• 需要有统一的网关收口，增加的开发量
• 服务间的调用产生了网络开销，降低了程序效率

 

为什么要用微服务

关于这个问题，小编只能说，好多公司都没搞清楚这个原因。更多的公司，进行微服务改造，是因为公司的CTO为了秀技术，又或者是拿公司资源学习做实验。

很多公司老项目，是springmvc框架开发，基于SOA开发设计的也很好。应用程序运行也很稳定，即便业务量上来了，通过简单的集群拓展就可以解决了。

那么为什么要用微服务？因为不用的话，公司的CTO会觉得自己很low，也怕镇不住小弟们。而公司空降过来的CTO，必须要对老程序进行一定规模的改造（否则，老板请你来是喝茶的吗？），而遇上这个微服务的风口，刚好是一展身手的机会，岂能容许错过？并且还会加上如何应对应用大并发，甚至会加上大数据Spark，搜索引擎ES等，反正能秀的一定要秀出来。

为了微服务而微服务

在改造过程中，有的CTO还是蛮尽心尽责的。但有的改造就不尽人意了，或许是技术能力问题，但更多的是做事态度问题。于是，在改造过程中，只是照葫芦画瓢，改了一个形似而已。

就说一个最简单，微服务的最基本要求，各个服务之间的数据存储是独立的。这也是为什么微服务会有分布式事务难题的原因。但是，读者们可以看看自己公司的应用，或者问问朋友公司的应用，有多少，从头到尾就一个mysql实例，在这个实例中就只有一个数据库。往往是一个工程，建立了二十几个所谓的微服务模块，然后，一个mysql实例（还特么是单点），mongo或许还能搞一个副本集集群，但redis又弄成了单点。最搞笑的是，每个微服务还启动了两个实例，美其名曰“集群”，但是，网关又弄成一个单点了。