微服务概述之微服务实践参考

前言

了解了微服务的好处，那么如何在实际生产中进行微服务的拆分？微服务中的微到底如何界定？服务拆分后如何进行协作？下面从开发工程师的角度来和大家聊一聊在实际开发中如何进行微服务的实践。

1. 服务如何拆分

微服务的拆分标准没有一个特别明确的概念，记住一条原则即可，就是不管服务如何拆分，都要明确定义好微服务系统的边界。举个例子，在电商系统中，可以有订单服务、用户服务、支付服务。订单服务还可细分为订单列表服务、订单详情服务等。这些微服务的系统边界需要开发团队自己来决定。
这样做的好处是，将一个大的业务拆分成了若干个小的业务，每个业务就是一个服务，将复杂业务简单化，编码也会相应的简单，代码的可读性和可扩展性都会增强。如果团队加入新人的话，也能减少学习成本。

2. 服务间的通信

服务拆分好之后，完成了开发就可以部署到独立的服务器上了。而服务之间是需要通信的，一般倾向于使用 HTTP 协议通信，大部分采用 RESTful 风格，这种通信机制与平台和语言无关，因此可以调用跨语言的微服务。例如，可以调用 Go语言编写的微服务，也可以调用 Java 语言编写的微服务。
服务之间还可以通过消息中间件进行通信。例如，服务A 将消息发送到消息中间件，服务 B通过订阅消息中间件进行后续的业务处理。
由于这种无状态的通信方式使得服务与服务之间没有任何的耦合，所以随着业务的发展，可以将服务更进一步细分，只要增加服务之间的调用接口即可。如果并发量继续增加，还可以像前面一样，将微服务做成集群，从而提高系统的负载能力。

3. 每个服务的数据库分别独立

在单体应用中，由于只有一个服务，所以业务共用一个数据库就行。而随着业务量的增加，数据库的表越来越多，就越来越难以管理和维护，数据库的性能也越来越慢。如果按照业务来拆分，这样数据库也就对应的独立了。每个微服务都有自己对应的数据库，这相当于将原来一个数据库的压力分散到多个数据库上。每个数据库的关系也会变得简单，开发也简单，数据库的性能也会有所提高。

总结

在微服务中，服务的拆分是一个重要的步骤。尽管没有明确的拆分标准，但需要明确定义好每个微服务系统的边界。将一个大的业务拆分成若干个小的业务，可以简化复杂业务，提高代码的可读性和可扩展性。在微服务架构中，服务之间需要进行通信。常见的通信方式是使用HTTP协议进行RESTful风格的通信，也可以通过消息中间件实现。这种无状态的通信方式使得服务与服务之间没有耦合，可以方便地进行拆分和扩展。每个微服务应该有独立的数据库，这样可以降低数据库的负载压力，简化数据库关系，提高性能。

微服务可以提高开发效率，降低学习成本，并且更好地适应业务的发展和变化。

大厂面试

面试官：你在公司中做微服务项目时，是依据什么来进行服务划分的？微服务设计一般都遵循了什么原则？
面试者：在进行微服务设计时，服务的数量相对于单体应用来说会比较多。考虑的重点就是如何准确识别系统的隔离点，也就是系统的边界。只有每个服务的边界确定了，才能在以后的开发中做到更好地协作。识别系统的隔离点，需要遵守下面几个原则。

1. 单一职责原则。让每个服务能独立、有界限地工作，每个服务只关注自己的业务，做到高内聚，服务和服务之间做到低耦合。
2. 服务自治原则。每个服务要能做到独立开发、独立测试、独立构建、独立部署、独立运行，与其他服务进行解耦。
3. 轻量级通信原则。让每个服务之间的调用是轻量级的，并且能够跨平台、跨语言调用。如采用 RESTful风格、利用消息队列进行通信等。
4. 粒度进化原则。对每一个服务的粒度把控，其实没有统一的标准，这个需要根据具体业务问题去确定。不要过度设计，服务的粒度随着业务和用户的发展而发展。

总结一句话。软件是为业务服务的，好的系统不是设计出来的，而是进化出来的。