一、什么是微服务
微服务是系统架构上的 一 种设计风格， 它的主旨是将 一 个原本独立的系统
拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP
的RESTful API进行通信协作。 被拆分成的每
一 个小型服务都围绕着系统中的某 一 项或 一
些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、 业务开发、
自动化测试案例以及独立部署机制。 由千有了轻量级的通信协作基础， 所以这些微服务可
以使用不同的语言来编写。
二、与单系统的区别
在以往传统的企业系统架构中， 我们针对 一 个复杂的业务需求通常使用对象或业务类
型来构建
一 个单体项目。 在项目中我们通常将需求分为三个主要部分： 数据库、 服务端处
理、 前端展现。 在业务发展初期， 由于所有的业务逻辑在
一 个应用中， 开发、 测试、 部署
都还比较容易且方便。 但是， 随着企业的发展， 系统为了应对不同的业务需求会不断为该
单体项目增加不同的业务模块； 同时随着移动端设备的进步， 前端展现模块已经不仅仅局
限于Web的形式， 这对千系统后端向前端的支持需要更多的接口模块。 单体应用由千面对
的业务需求更为宽泛， 不断扩大的需求会使得单体应用变得越来越腕肿。 单体应用的问题
就逐渐凸显出来， 由于单体系统部署在 一 个进程内， 往往我们修改了 一 个很小的功能， 为
了部署上线会影响其他功能的运行。 并且， 单体应用中的这些功能模块的使用场景、 并发
量、 消耗的资源类型都各有不同， 对于资源的利用又互相影响， 这样使得我们对各个业务
模块的系统容量很难给出较为准确的评估
三、如何实施微服务
微服务虽然有很多优点，但是也因为服务的拆分引发诸多原本在单体应用中没有的问题。
1、运维的新挑战： 运维人员需要维护的进程数量会大大增加
2、接口的一致性：虽然拆分了服务，但是业务逻辑依赖不会消除。只是从单体应用中的代码依赖为服务间通信依赖。接口的改变 双方需要协调改变。
3、分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内，
它们只能通过通信来进行协作， 所以分布式环境的问题都将是微服务架构系统设计
时需要考虑的重要因素， 比如网络延迟、 分布式事务、 异步消息等。
