微服务系统接口设计（微服务方案设计）

本篇文章给大家谈谈微服务系统接口设计，以及微服务方案设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务系统接口设计的知识，其中也会对微服务方案设计进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微服务入门｜微服务架构怎么设计
• 2、前后端分离微服务架构如何设计
• 3、springcloud（二）微服务接口规范

微服务入门｜微服务架构怎么设计

将一个单体应用拆分成一组微小微服务系统接口设计的服务组件微服务系统接口设计，每个微小微服务系统接口设计的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据 。

通过以上的定义描述，我们可以基本确定给出微服务的节特征：

用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：

在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：

1、客户端如何访问这些服务微服务系统接口设计？

2、每个服务之间如何进行通信？

3、多个微服务，应如何实现？

4、如果服务出现异常宕机，该如何解决？

以上这些都是问题，需要一个个解决。

在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。

现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：

此时，后台有N个服务，前台就需要记住管理N个服务，一个服务 下线 、 更新 、 升级 ，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。

除微服务系统接口设计了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务操作时，往往是跨业务模块进行操作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。

基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：

网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为 单点故障 点或者性能的瓶颈。

最终，添加了网关(API Gateway)的业务架构图变更为如下所示：

所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。进程间通信的方案已经比较成熟了，现在最常见的有两大类： 同步调用、异步消息调用 。

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST 和 RPC

基于REST和RPC的特点，我们通常采用的原则为： 向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。需要付出的代价是一致性的减弱，需要接受数据 最终一致性 ，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现 幂等性 ，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的 Broker，作为中间代理池。

常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。

最终，大部分的服务间的调用架构实现如下所示：

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。这就出现了新的问题：

这就是服务的发现、识别与管理问题。解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。

具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。当服务下线时，服务管理框架会发送服务下线的通知给其他服务。

常见的服务管理框架有：Zookeeper等框架。

如上的问题解决方案有两种具体的实现，分别是： 基于客户端的服务注册与发现 、 基于服务端的服务注册与发现 。

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。

优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：

前后端分离微服务架构如何设计

前端

前端开发人员专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。

比如：

一般前端工作包括六个部分：

后端

如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。

一般后端工作包括五个部分：

1、与产品经理对接需求

2、业务 API 接口开发：根据根据需求文档进行业务接口开发

4、接口对接：与前端开发人员接口对接

5、前后端联调测试：包括页面展示以及接口数据

6、bug修复

前端开发技术栈

h5 、 css 、 nodejs / vue / angular / react 、 webpack 、 hbuilder / vscode 等

后端开发技术栈

SpringCloud / Springboot 、 SpringMVC 、 ORM 框架、数据库、缓存框架（ Redis ， Codis , Memcached 等），大数据框架（ Hadoop / Spark / hive / Hbase / Storm / ES / Kafka ）等等

技术选型

最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。

数据格式

后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用 REST 风格以 JSON 格式提供数据。

接口设计

一个接口设计的好坏，直接影响到前后端的一些沟通协调问题。

依笔者的经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。

接口容量问题

一个接口的业务容量大小，往往代表前后端工作量的大小。

如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口 Ajax 异步处理；

如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。

一、前后端分离的思想要转变

不能老是按照传统WEB（ js/h5/css/ 后端代码放在一个工程）开发思维去看待前后端分离

二、沟通成本问题

以前传统 WEB 开发，开发人员从需求到设计到开发基本上是一个人。

而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。

三、组织结构问题

康威定律

第一定律： Communication dictates design （组织沟通方式会通过系统设计表达出来）

第二定律： There is never enough time to do something right, but there is always enough time to do it over （时间再多一件事情也不可能做得美，但总有时间做完一件事情）

第三定律 ： There is a homomorphism from the linear graph of a system to the linear graph of its design organization （线型系统和线型组织架构间有潜在的异质同态特性）

第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems （大的系统组织总是比小系统更倾向于分解）

康威定律说明以下几点

四、部署及监控运维

前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。

总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做得比较好的

springcloud（二）微服务接口规范

微服务接口规范是指controller层的规范
controller的功能应该有以下五点：
1.参数校验
2.调用service层接口实现业务逻辑
3.转换业务／数据对象
4.组装返回对象
5.异常处理 关于微服务系统接口设计和微服务方案设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务系统接口设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务方案设计、微服务系统接口设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。