什么是微服务架构
“微服务”一词源于Martin Fowler的名为Microservices的博文， 可以在他的官方博客 上找到： 巨nfowler.com/articles/microservices.html。
简单地说， 微服务是系统架构上的一种设计风格， 它的主旨是将一个原本独立的系统 拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP 的RESTful API进行通信协作。 被拆分成的每一个小型服务都围绕着系统中的某一项或一 些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、 业务开发、 自动化测试案例以及独立部署机制。 由千有了轻量级的通信协作基础， 所以这些微服务可 以使用不同的语言来编写。
与单体系统的区别
在以往传统的企业系统架构中， 我们针对一个复杂的业务需求通常使用对象或业务类 型来构建一个单体项目。 在项目中我们通常将需求分为三个主要部分： 数据库、 服务端处 理、 前端展现。 在业务发展初期， 由于所有的业务逻辑在一个应用中， 开发、 测试、 部署 都还比较容易且方便。 但是， 随着企业的发展， 系统为了应对不同的业务需求会不断为该 单体项目增加不同的业务模块； 同时随着移动端设备的进步， 前端展现模块已经不仅仅局 限于Web的形式，这对千系统后端向前端的支持需要更多的接口模块。 单体应用由千面对 的业务需求更为宽泛， 不断扩大的需求会使得单体应用变得越来越腕肿。 单体应用的问题就逐渐凸显出来， 由于单体系统部署在一个进程内， 往往我们修改了一个很小的功能， 为 了部署上线会影响其他功能的运行。
并且， 单体应用中的这些功能模块的使用场景、 并发 量、 消耗的资源类型都各有不同， 对于资源的利用又互相影响， 这样使得我们对各个业务 模块的系统容量很难给出较为准确的评估。 所以， 单体系统在初期虽然可以非常方便地进 行开发和使用， 但是随着系统的发展， 维护成本会变得越来越大， 且难以控制。 为了解决单体系统变得庞大脯肿之后产生的难以维护的问题，微服务架构诞生了并被 大家所关注。 我们将系统中的不同功能模块拆分成多个不同的服务， 这些服务都能够独立 部署和扩展。 由于每个服务都运行在自己的进程内， 在部署上有稳固的边界， 这样每个服 务的更新都不会影响其他服务的运行。 同时， 由千是独立部署的， 我们可以更准确地为每 个服务评估性能容量， 通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置， 以及给出较为准确的系统级性能容量评估。
如何实施微服务
在实施微服务之前， 我们必须要知道， 微服务虽然有非常多吸引人的优点， 但是也因 为服务的拆分引发了诸多原本在单体应用中没有的问题。
• 运维的新挑战：在微服务架构中， 运维人员需要维护的进程数量会大大增加。 有条 不紊地将这些进程编排和组织起来不是一件容易的事， 传统的运维人员往往很难适 应这样的改变。 我们需要运维人员有更多的技能来应对这样的挑战， 运维过程需要 更多的自动化， 这就要求运维人员具备一定的开发能力来编排运维过程并让它们能 自动运行起来。
• 接口的一致性：虽然我们拆分了服务， 但是业务逻辑上的依赖并不会消除， 只是从 单体应用中的代码依赖变为了服务间的通信依赖。 而当我们对原有接口进行了一些 修改， 那么交互方也需要协调这样的改变来进行发布， 以保证接口的正确调用。 我 们需要更完善的接口和版本管理， 或是严格地遵循开闭原则。
• 分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内， 它们只能通过通信来进行协作， 所以分布式环境的问题都将是微服务架构系统设计 时需要考虑的重要因素， 比如网络延迟、 分布式事务、 异步消息等。 尽管微服务架构有很多缺点和问题， 但是其实现的敏捷开发和自动化部署等优点依然 被广大优秀架构师和开发者所青眯， 所以解决这些问题就是这几年诸多架构大师努力的目 标。 在架构师对于一个大型系统架构的设计与实施的过程中， 面对环境、 资源、 团队等各 种因素的影响， 几乎不会出现完全相同的架构设计。 对于微服务架构而言更是如此， 由并没有一个标准或正式的定义，每位架构师都根据自身理解与实际情况来进行设计，并在 发展的过程中不断演化与完善。 经过多年的发展，MartinFowler在Microservices 一文中， 提炼出了微服务架构的九大特性，用于指导大家设计架构。
服务组件化