微服务设计的几点思考

接触微服务也有几个月时间了，平时断断续续的会有一些关于微服务设计的思考，现在做个小结，与大家分享。

先上一张简单的示意图

底部是用到的数据存储设施，中间部分是今天的主角，微服务群，最上面是一个统一入口，网关。

微服务应该分为核心微服务和业务微服务

理想的系统应该是小核心，大业务。核心简单、精干、稳定；业务复杂、规则多、易变。业务调用核心，但是核心不会调用业务，需要的话可以走消息，解耦。
如图所示，微服务群中，深蓝颜色的块表示的就是核心微服务。icare-customer，用户服务，基本上每一个系统都需要；icare-account，账户服务，也是刚需；icare-order，订单服务，交易的系统必要组件。仔细想想，这些服务一经开发完成，很少会有大的变化。

核心服务的一个特点是，绝大多数业务都需要调用核心服务。是的，核心服务是基石。为了业务方调用方便，可以提供一些核心的接口出去，比如icare-XXX-share。注意，核心服务也能够单兵直接对外提供服务。

业务服务不需要对其它微服务提供接口，如果有交互的需要，走消息。icare-checkup，体检服务；icare-car，用车服务；icare-ele，外卖服务 …

应该从url上就区分内部服务和外部服务

会遇到一些场景，有些服务只希望对系统内部的微服务开放，不希望app之类的客户端有访问的能力。
我的想法是从url上来区分，比如所有内部服务url与”/inner/”开始，然后在网关那边做一下配置，拦截所有inner开头的url。
微服务一般来说是http的，http最显著的部件是url，那么就从url上找解决之道。

gateway很重要

用node, nginx, zuul都可以做gateway。
gateway至少有以下好处:
1. 客户端统一入口，简化客户端的服务调用。
2. 安全验证的一道关卡，把非法访问拦截掉，保护后面的微服务。
3. 承担负载均衡的角色

最后

以上就是标致路人为你收集整理的微服务设计的几点思考的全部内容，希望文章能够帮你解决微服务设计的几点思考所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。