1、导读

近年来微服务架构的火热，很多公司都开始转向微服务架构的开发，博主也使用该架构进行了部分项目的开发，为了让公司的开发团队成员更好的掌握微服务的开发，特进行记录便于后续新人的学习与了解；如有其它大神看到本系列有错误之处望指出，O(∩_∩)O

2、什么是微服务

那什么是微服务架构呢？简单说就是将一个完整的应用（单体应用）按照一定的拆分规则拆分成多个不同的服务，每个服务都能独立地进行开发、部署、扩展。服务于服务之间通过注入RESTful api或RPC的通讯调用；正因为微服务架构中，服务之间是相互独立的，所以不同的服务可以使用不同的语言来开发，或者根据业务的需求使用不同类型的数据库，而微服务的宗旨在于通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

3、微服务的优点

那么会有同学问了，为什么我们要用微服务？ 从上面的介绍相信大家已经看到一个我们常听到的关键词：解耦！ 我们用一张图来看一下我们以前的单体应用：

idea设置微服务启动的内存大小 idea开发微服务_微服务优缺点


在不考虑前后分离模式的情况下：以前我们的WEBUI是和单体应用一并打包发布的；那么我们罗列几个问题思考一下：

  • 随着时间的推移项目功能不断增加，体积是不是会越来越臃肿？
  • 随着技术的更新，以前开发的技术架构（如：SSH）一旦需要更换（SSM） ，那么是多痛苦的事情？
  • WEBUI有所变更，我们是不是只能重新进行项目部署？
  • 项目越大，部署时间是不是越长？
  • 项目中众多模块，只要有一个模块故障（如：内存溢出），是不是导致整个项目挂了？

还有很多很多问题，这些都是单体应用的问题所在？那么如何解耦？

  • 各个模块 独立一个应用、数据库、独立运行 （即独立服务）
  • 每个服务（用户模块） 提供RESTful api 供其它服务调用

那么看一下是否解决了以上单体应用例举的几个的问题？
1、因为模块已经拆分，每个模块都是一个服务，应用的体积是拆分出去的；
2、每个独立服务，进行技术改造只需要修改某个模块的（服务）相对单体应用会简单很多；
3、WEBUI也抽离成为独立运行项目，前后分离后，各自分工，功能需求不变UI所有变化的情况下，只会改动WEBUI项目；
4、既然各模块已经抽离成为独立个体服务，那么即便某个模块故障，也不会导致其它模块的运行

引用某书中概括微服务的优点：
  1. 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护
  2. 这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。
  3. 微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能
  4. 微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库

4、微服务的缺点

  1. 运维开销
    更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。
  2. DevOps要求
    使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。
  3. 隐式接口
    服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
  4. 重复劳动
    在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。
  5. 分布式系统的复杂性
    微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
  6. 事务、异步、测试面临挑战
    跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。

5、单体架构和微服务架构如何抉择？

聊了那么多微服务并非是要大家放弃单体架构，都去应用微服务，前面的优缺点已经介绍过，在选择一种技术架构的时候，首先是对项目、团队、成本的评估；

比如：项目相对简单，更新较少，项目价格还不高，我们可以直接采用单体架构即可，没必要杀鸡用牛刀；

总之选择自己合适的就好，两种架构根据企业自身情况选择；

下一篇：Spring Cloud 介绍