Spring-cloud微服务实战【一】：微服务的概念与演进过程

本文是一个系列文章，主要讲述使用spring-cloud进行微服务开发的实战。在开始之前，我们先说一下从传统的单一部署架构到微服务的发展过程，以便让童鞋们更好的理解微服务的概念与演进过程。

1.单体架构
  在互联网时代早期，彼时还没有微服务的概念，企业开发应用，将所有功能都集中到一个应用中，典型的特征是tomcat + servlet + jsp + mysql，然后将应用打包成一个war包发布。

2.集群架构
  随着时间的推移，用户数量越来越多，访问量越来越大，单体架构已经无法满足需求，此时，企业使用多台服务器集群部署的方式，通过横向复制来解决该问题。

3.分布式应用（垂直架构）
  随着业务量继续增大，集群部署带来的性能提升越来越小，集群架构已经无法满足需求，此时分布式应用应运而生：将单个应用拆分为几个互不相关独立运行的应用，但是应用之间可能会有数据冗余。比如商品应用中有用户模块，订单应用中也有用户模块，他们的用户数据和用户应用中的用户数据是相同的，导致了应用间的数据冗余。

4.微服务架构(SOA)
  为了解决上面的分布式应用中数据冗余的问题，SOA架构应运而生：面向服务架构。所谓面向服务：即从服务的角度来拆分应用，比如一个完整的电商，可能会拆分为用户服务、商品服务、订单服务、库存服务、物流服务等等，每个服务的业务划分边界清晰，和其他服务没有重合，也就不存在数据冗余的情况，服务与服务之间采用RPC或者HTTP方式进行通信。SOA可以认为是一种设计思想，而微服务是一种将该思想落地的一种方式，比如spring cloud。具体什么是微服务？业界没有统一的定义，一般认为微服务架构是一种将单体应用拆分为一组互相独立运行的应用的方法，应用之间一般通过轻量级通讯机制进行通信（一般是HTTP方式）。

5.为什么需要微服务？
要回答这个问题，首先要了解单体架构的应用有什么问题。

单体应用的问题：
1.复杂性高，模块与模块之间的边界划分模糊，修改代码困难，每一行代码都可能以一种你意想不到的方式被其他代码引用。
2.代码可读性、可维护性差。由于所有代码都耦合到一起，模块众多，代码量大，对代码的可读性和可维护性带来的极大的困难。
3.技术替换成本高，假如想换其他的实现方式，或者换一种语言来实现，只能全部重来，无法局部替换。
4.部署风险高，每个小改动都会导致整个应用的重新部署，部署后的线上缺陷以及回滚操作都不可控。

针对以上缺点，即可总结我们为什么需要微服务:
1.微服务架构中的每一个应用都是独立的应用，应用的边界清晰，功能职责单一，不会出现应用间的模块或者数据冗余。
2.由于每个应用的职责单一，因此代码量相对较小，代码的可读性以及可维护性都会很好。
3.技术替换成本低，比如我的订单服务可以使用JAVA应用，我的库存服务可以是Python应用，而我的物流服务可能是Nodejs应用，应用间不需要保持开发语言一致，可灵活选型。
4.部署风险低，某一个应用挂掉不会导致整个应用挂掉(当然要求服务提供方和消费方都做好服务降级和熔断)，一个应用的部署也不会影响其他应用，并且这种方式能满足现代互联网快速迭代的需求。

当然，微服务也不是没有缺点：
1.首先微服务的调用链路长，因此针对这种很长的链路调用排查线上问题就变得尤为困难，此时，对微服务中的每个应用的监控就显得尤为重要。
2.微服务众多，服务间的调用关系--即服务治理成本较高。
3.微服务的技术成本更高（分布式缓存，分布式事务，分布式一致性等问题）。

了解了微服务的一些概念，就让我们一起开始微服务的实战吧！下一篇，敬请期待！
> 本文由博客一文多发平台 [OpenWrite](https://openwrite.cn?from=article_bottom) 发布！