微服务架构浅谈

什么是微服务？

近年来，“微服务”这一概念犹如雨后春笋般传播开来，它主要用于表述一种软件应用的开发部署的设计风格。虽然微服务并没有一个统一明确的定义，但是总体来讲，其风格是将小的服务开发成独立的应用服务，并运行在各自的进程中。每个服务可以通过自动化部署来独立发布，各个服务之间通过http这样的轻量级协议进行通信。另外，每个服务甚至可以通过不同的技术甚至语言来实现。

---

与单体式服务对比

一个单体式应用在不断开发迭代的过程中，随着代码量的不断增多，整个应用将变得越来越复杂，一方面这将使得整个系统的维护变得耗时且困难，另一方面过于庞大的应用也将带来开发的效率低下，试想一个应用的启动时间长达数十分钟甚至更久，这对整个开发团队来说一定会很痛苦。另外，对于单体式服务，当开发者的修改内容只影响应用很小一部分功能时，也不得不将整个服务重新部署，大大降低了开发的敏捷性。而微服务的风格恰恰解决了上述单体式服务的缺点。

---

与SOA架构对比

SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。而企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，因此更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。

---

微服务的优劣总结

• 优势
  
  1. 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
  2. 这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。
  3. 微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
  4. 微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。
• 不足
  
  1. 微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
  2. 部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相对比，一个微服务应用一般由大批服务构成，当微服务的数量达到一个很高的量级，如数百个时，其开发、维护以及部署都将成为非常麻烦的事情。