什么是微服务架构
简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或者一些耦合度较高的业务功能进行构建，并且每个服务都维护者自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协议作基础，所以这些微服务可以使用不同的语言来编写。
与单体的区别
单体特点：
- 业务需求通常使用对象或者业务类构建一个单体项目。
- 通常将需求分为三个主要部分：数据库、服务端处理、前端展示。
- 前期，由于所有业务逻辑在一个应用中，开发、测试、部署都比较容易。
- 由于业务需求更广泛，往往我们修改了一个很小的功能，为了部署上线会影响其他功能的运行。
- 对各个模块的系统容量很难给出较为准备的评估。
- 随着系统的发展，后期维护成本会越来越大，且难以控制。
微服务架构特点：
- 系统中的不同模块被拆分成了不同的服务，这些服务都能够独立部署和扩展。
- 由于每个服务在自己的进程内，在部署上有稳固的边界，因此每个服务的更新都不会影响其他服务的运行。
- 由于是独立部署，可以更准确的为每个服务评估性能容量，更容易的发现体统的瓶颈位置，以及给出较为准确的系统级性能容量评估。
如何实施微服务
在实施微服务之前，我们必须要知道，微服务虽然有许多吸引人的优点，但是也因为服务的拆分引发了诸多原本在单体应用中没有的问题。
- 运维的新挑战：在微服务架构中，运维人员需要维护的进程数会大大增加，运维人员需要有条不紊的将这些进程编排和组织起来，传统的运维人员很难适应这样的变化。我们需要运维人员有更多的技能来应对这样的挑战，运维过程需要更多自动化，这就要求运维人员具备一定的开发能力来编排运维过程并让它们能自动运行起来。
- 接口的一致性：虽然拆分了服务，但业务逻辑间的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。我们需要更完善的接口和版本管理，或是严格的遵循开闭原则。
- 分布式的复杂性：由于拆分后各个微服务都是独立部署并且运行在各自的进程内，他们只能通过通信来进行协作，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如忘了延迟、分布式事物、异步消息等。
尽管微服务架构有很多缺点和问题，但是其实现的敏捷开发和自动化部署等优点依然被广大优秀架构师和开者的所青睐。