微服务架构

微服务产生的背景

在网站初期，网站的架构比较简单，通常把所有代码统一打包部署的服务器上 以java项目为例，例如有5个程序员，他们各自开发自己的功能模块，然后提交，运维人员取得所有代码，编译成war包，然后部署到服务器 后来项目越来越大，功能模块越来越多，小的功能维护和bug修改也越来越多 整个开发流程的时间也会变得很长，即使只修改一个小问题或者升级一个小需求，就需要花费十几分钟甚至几十分钟对所有代码进行编译和部署，以验证自己的更改是否正确，很可能就需要大家一起加班 这是第一个问题：开发、测试、部署的效率低下 在项目变大的同时，所需要的技术也会变得越来越多，但这些技术有些是不兼容的，比如混合使用C++和Java就很难，在这种情况下，通常做法是放弃那些适合但不兼容的技术，而选择不那么适合但兼容的技术 这是第二个问题：不利于针对特定需求选择合适的技术 还有一个很严重的问题 当网站变大后，系统资源不足，需要集群扩展来解决 比如网站有3个模块，各自的资源占比为： A - 10% B - 5% C - 85% 模块C是瓶颈，由于他们都在一个WAR包中，做扩展时就需要添加一台性能可以支撑整个WAR包的服务器，这样明显会造成资源浪费 这是第三个问题：系统资源浪费

微服务是如何解决问题的？

例如网站有3个模块，A B C 之前的做法是把所有模块一起编译，部署到一台服务器，服务器扩展时，在新服务器上再部署一整套

微服务的思路是把每个模块作为一个独立的应用进行单独编译、单独部署，各个模块间通过服务调用的方式进行沟通协作

这样做有什么好处呢？ （1）提高了开发部署效率 开发人员可以通过重新编译部署单个子服务的方式来验证自己的更改，而不再需要重新编译整个应用，从而节省了大量的时间 （2）解决了技术兼容问题 由于每个子服务是独立的，因此各个服务内部可以自行决定最为合适的实现技术，使得这些子服务的开发变得更为容易 （3）资源利用最大化 如果当前系统的容量不够了，那么我们只需要找到成为系统瓶颈的子服务，并扩展该子服务的容量即可 （4）提高系统稳定性 对于每个子服务，都可以做高可用集群，保证系统整体的稳定性

微服务的定义

微服务架构是一种架构模式，提倡将单一应用划分成一组小的服务，服务之间互相协调、互相配合 每个服务运行在独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（如RESTful API） 每个服务都围绕着具体业务进行构建，能够被独立的部署到生产环境

微服务带来的问题

微服务带来好处的同时，也带来了一些问题，主要就是性能问题 例如一个功能在之前的模式下，需要的数据可以一起都取回来，而在微服务模式下，可能需要调用多次不同的服务才可以，服务调用是有成本的，多次调用的性能很可能无法接受 对于这个问题，通常的解决思路是仔细设计微服务的粒度，不要太小，来尽可能较少各种跨服务调用的消耗 这就对于设计能力提出较高要求