为什么使用微服务

1.单机服务

单机特点：在一台linux机器上部署一个tomcat服务，然后由浏览器发起http请求，tomcat将请求转发到项目由springmvc处理，经过controller->service->mapper->mysql.返回数据。
优点：维护简单，就一台服务器。
缺点：可处理的请求量有限
单机服务在公司刚成立时还是可以用的，当公司用户量慢慢增多，发现mysql服务器cpu，内存都还撑得住，但web服务器不行了，cpu和内存使用率陡增，甚至在高峰期出现宕机的情况。此时我们想到的是增加机器，变成一个集群。
2.集群服务

此时我们就多加了几台web服务器，从单机变成了一个集群，甚至我们可以写一个脚本，当web服务器压力过大时动态增加web服务器。这下web服务器的压力不大了，我们就这样安稳的过上了几个月。然而有一天服务器又出问题了：先是mysql服务器cpu标高，然后是web服务器宕机。此时我们会发现虽然可以通过集群来解决访问并发问题。但服务QPS高->sqlQPS高->mysql的cpu标高->sql执行效率变低->请求响应时间变长->web服务器吞吐量变低->服务宕机.通过上诉我们会发现mysql的性能是整个服务的痛点，此时我们会选择使用主从来提高mysql性能，读走从库，写走主库：

我们又一次解决了问题很开心，但我们事后一想，有些东西我们可以做缓存啊，就像mysql有读缓存一样，有些不太变的数据做缓存后就不用访问mysql了，这样sql的QPS不就更少了，而且缓存也可以剩下sql执行的时间，请求响应的时间也能缩短，缓存真是个好东西，我们的架构就变成了这样：

现在看起来不错，但随着业务的发展你会发现：
1.所有业务放在一个项目里开发维护成本很高，可能十几个程序员在改一个项目，一个项目同时有很多个需求，开发周期也不一样，这可能带来很多额外的维护成本。
2.所以业务线在一起，一个业务宕机，所以业务都宕机，业务隔离性很差。
3.随着业务的发展，大表越来越多，即使一个简单的sql执行时间也很长，接下来可能要面临的是分库分表，甚至是多主多从。一个项目维护成本过高
3.微服务

我们在构建微服务时吸取了前面的经验：
1.每一个微服务都使用的集群，redis缓存，mysql集群
2.服务之间使用https请求或rpc调用，调用失败可以使用服务降低
3.服务之间相互隔离（服务隔离，缓存隔离，mysql隔离）
微服务虽然解决了前面集群所没解决的问题，但也带来了新的问题：
1.服务之间如何进行发现，如果写在本地维护成本太高。
2.线上bug比较难查，因为调用链比较复杂
3.一个服务拆成了多个服务，原来的一个请求微服务内部可能需要多次http请求或rpc调用，请求时间可能边长，接口性能变差。
4.调用某个微服务失败，如何进行服务降低，当一个微服务是集群时如何选择负载策略。
5.项目中配置文件如何管理。
此文章同步到了我个人公众号：java面试工程师。关注公众号更加便于查阅。