戳蓝字“CSDN云计算”关注我们哦！

过去几年来，“微服务架构”这个术语出现了，它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。近几年微服务吵的也比较火，那么为什么微服务会受到这么多的关注？今天，我们就来看看有关于微服务的精华问答吧

1

Q：微服务的主要作用是什么？

A：微服务被用来创建一些复杂的系统，这些系统由小型且自治的服务构成，而这些服务通过各自的API接口进行数据交换，同时有相应的有界上下文明确它们的范围，一定程度来说，微服务就是面向对象编程方法所期待的东西。

2

Q：微服务应该如何拆分？

A：服务拆分有3个层次：

第一，是把技术性功能拆分出来比如，短信服务、邮件服务；这是最简单的没有大的难点；无非是接口管理优化一下。

第二，是把并行的无交集的业务流拆分出来；如果业务库拆分了，则难点是跨库表连接如何处理。一般只能把需要连接的数据进行同步。

第三，是将某业务流中串行的业务节点拆分出来；业务节点分别在不同jvm中运行，则难点是分布式事物。

跨jvm的分布式事物，可以用micro-datasource解决。

3

Q：如何把应用分成若干个小服务？

A：第一，按业务功能分解，将应用分解成能产生业务价值的最小单元。第二，对于跨多个业务的类（如订单会被订单管理、订单交付多个服务用到）用领域驱动设计（DDD），使用子域和边界上下文的概念来着手解决。

4

Q：在微服务, 前后端分离的场景下，服务端的设计的接口应该是复合性的接口还是原子性的接口？例如: 一个web首页, 需要展示帖子列表、推荐帖子、活动信息等多个模块，那么服务端应该分别提供 查询帖子列表，查询推荐帖子列表，查询活动信息列表等多个原子性接口。还是给前端提供一个复合接口, 一次性返回所有数据?

A：在微服务的系统架构体系内，倡导的是解耦！从后端的角度看，业务系统的设计（或者说数据库设计）应该遵循领域建模的原则，给前端提供的接口，无非是对模型（表）的CRUD，那么对于活动信息、帖子信息等，明显不属于一个领域模型。如果做耦合会不利于后面的

业务扩展。http接口的定义要与实际的交互相结合，在满足架构设计的原则下，也需要和前端进行沟通，一起制定。

5

Q：现在有个微服务项目，项目框架搭建中，多个微服务创建的过程中会用到一些spring boot常用的依赖，比如spring-boot-starter-web，spring-cloud-starter-eureka-server等必须的依赖，难道每个服务的pom文件中都要有这样的依赖吗，如果每个pom文件都这样，后期jar升级是不是很麻烦，于是做了一个共通的jar，把所需要的共通依赖加载进来，可是后面发现好像会有jar冲突的现象，不知道有什么好的解决方案？

A：第一步，创建一个maven工程作为父工程(此工程放子工程公共依赖);第二步，把Packaging标签改为pom并保存；第三步，点击Overview视图找到Modules标签,标签右边有两个按钮一个Add,一个Create)；第四步，点击Create标签创建子工程,子工程自动依赖父工程pom,子工程特殊依赖只要在子工程pom加入即可。

----------------  完  --------------

1.微信群：

添加小编微信：color_ld，备注“进群+姓名+公司职位”即可，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！

2.征稿：

投稿邮箱：liudan@csdn.net；微信号：color_ld。请备注投稿+姓名+公司职位。

推荐阅读

• 云计算到底是怎么玩的？

• 企业云存储建设之路

• AI in 美团：吃喝玩乐背后的黑科技

• 开除“野狗”式程序员，团队的效率提高了

• Windows 成“弃子”，Linux 终上位？

• 可替代Android的6大开源移动操作系统

• 程序员求助：被领导强行要求写Bug该怎么办？网友的回答让我笑翻

点击“阅读原文”，打开 CSDN App 阅读更贴心！

喜欢就点击“好看”吧！