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 发布！