我要何时使用微服务架构?又如何将应用程序分解为微服务?分解后，要如何去搭建微服务架构?同时，在微服务架构中，因为会涉及到多个组件，那么这些组件又可以使用什么技术来实现呢?接下来的几个小节中，我们将对这些问题进行详细的讲解。

微服务的拆分

对于一般的公司而言，实践微服务有非常大的技术挑战，所以并不是所有的公司都适合将单体架构拆分成微服务架构。一般来说，微服务架构比较适合未来有一定的扩展复杂度，且有很大用户增量预期的应用，例如一些新兴的互联网公司应用。这些公司在创业初期，不可能买大量的机器或者很贵的机器，但是又必须考虑应对成功后巨量的用户问题，这时微服务架构就成了最好的选择。除此之外，对于那些项目规模较大、业务复杂度较高，且需要长期跟进的项目，也适合考虑使用微服务架构。

在决定使用微服务架构后，所面临的另一个问题就是如何将系统拆分为微服务。对于微服务的拆分，可以参考如下几点建议：

①通过业务功能分解并定义与业务功能相对应的服务。

②将域驱动设计分解为多个子域。

③按照动词或用例分解，并定义负责特定操作的服务。例如一个负责完成订单的航运服务。

④通过定义一个对给定类型的实体或资源的所有操作负责的服务来分解名词或资源。例如一个负责管理用户帐户的帐户服务。

由于每个公司项目的实际情况不同，所以微服务的拆分在实际操作时，会涉及到很多不同的细节问题，这里就不一一描述了，但总体来说，项目在拆分时按照上述几点建议即可。

微服务架构的组件

我们先来了解下微服务架构中所涉及到的一些常见组件。这些组件的名称及其作用如下：

①服务注册中心：注册系统中所有服务的地方;

②服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己;

③服务发现：服务调用方从服务注册中心找到自己需要调用服务的地址;

④负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点;

⑤服务容错：通过断路器(也成熔断器)等一系列的服务保护机制，保证服务调用者在调用异常服务时快速的返回结果，避免大量的同步等待。

⑥服务网关：也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能;

⑦分布式配置中心：将本地化的配置信息(properties、yml、yaml等)注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。

微服务架构的搭建

通过前两个小节的学习，我们已经了解了如何将传统业务拆分为微服务，并熟悉了微服务架构中所涉及到的组件。为了使读者在整体上对微服务架构有一个认识，下面我们通过一张图来讲解如何搭建一个微服务架构，如图：

简单微服务架构在图中，部署了一系列的微服务，每个微服务都会访问自己的数据库(Database)。当这些微服务启动时，会将其信息注册到服务注册中心(Service Registry)， 在客户端发送请求时，请求首先会被API网关(APIGateWay)拦截，API网关会读取请求数据，并从注册中心获取对应的服务信息，然后API网关会根据服务信息调用所需的微服务。

小提示：

图展示的只是一个简单的微服务架构，然而要判断一个架构是否是微服务架构，还需要满足以下几点要求：

①根据业务模块划分服务种类;

②每个服务可独立部署且相互隔离;

③通过轻量级API调用服务;

④服务需保证良好的高可用性。

只有满足以上几点要求的架构，才能称之为微服务架构，所以在搭建微服务架构时，一定要注意这些问题。