微服务管理系统（1.微服务管理-11.缓存-3.实践-缓存使用）

本文目录

• 1.微服务管理-11.缓存-3.实践-缓存使用
• 如何设计实现真正的响应式微服务系统
• 1.微服务管理-17.用户管理-0.概述

1.微服务管理-11.缓存-3.实践-缓存使用

微服务实践目录 ，可以参见连接。

缓存系列包括： 1.微服务管理-11.缓存概述 1.微服务管理-11.缓存-0.技术 1.微服务管理-11.缓存-1.多级缓存设计 1.微服务管理-11.缓存-2.典型缓存架构设计 1.微服务管理-11.缓存-3.实践-缓存使用 1.微服务管理-11.缓存-4.总结

在前面的几篇文章中讨论了很多关于缓存使用时要注意的事项。但在实际的工作中在哪些地方考虑这些事项其实还是不明确。为了帮助读者在生产中更好的使用缓存，本文主要以例子的方式说明在生产环境中使用缓存的方式。

结合前面几篇文章中的内容，并通过尽量的减少对于（相对）慢速服务/设备的访问来提高业务处理速度。但在业务处理过程中减少对于慢速服务/设备的访问并不一定就可以提升业务处理速度，并还有可能带来其他的问题。所以，这里展示几个例子来解释这些问题，并提供可用的生产环境方案。

在前几篇文章中出现过大量请求的时候的一个终极方案，如下：

这个方案参照了之前使用cdn缓存业务接口的方式来设计。通过OpenResty中支持的脚本语言Lua去控制本地返回还是使用Redis中结果返回。还有如果发生miss之后还需要调用后端服务来更新缓存。

这种方式的缓存的特点：适合IO密集型业务中，不适合计算密集型业务。并在业务过程中查看的业务占系统业务的绝大部分。例如：大型线上商城中的商品展示，新闻网站，网站门户，微博/陌生人社交，音视频服务，图片网站等。

在实际的缓存更新过程中一般有以下几种方式来更新缓存:

这几种方式针对不同的缓存模型来进行。

被动更新的特点在于有一个系统中的触发源去触发数据的更新动作。主动更新的特点在于只有用户在使用系统的特定功能时才会触发更新的动作。被动更新可以保证缓存和数据源之间的数据永远是一致的，并且不需要过多的补偿机制来保证数据一致性。主动更新的方式就会发生缓存和数据源中数据不一致的问题。所以，在后面会讨论在主动更新模式下尽量保证数据一致性的方式。

定时更新的方式在很多地方都有使用，例如CDN的定时溯源的机制就是以这种方式运行的。

事件更新中最核心的概念是 事件 ，这里的事件最好是在领域驱动设计中的事件风暴阶段中这里出来的事件。因为这种事件代表着业务发生的动作，也代表着业务价值的流动。

在微服务架构模式下，任务、定时器都会由一个任务调度中心来完成。所以，在使用定时触发缓存更新时还是使用分布式任务调度中心来完成任务的调度工作。这样可以保证同一时间只有一个实例在处理。以这种方式简单的进行排他工作，防止同时操作缓存的问题。

用户触发更新也可以称为非固定周期更新，因为用户的触发时间是不确定的、任何时候都可能。有一种随机数的产生方式就是使用类似的机制：操作系统使用内核接受到中断的时间点作为随机数使用。所以，用户触发更新的方式就是一种随机发生的缓存更新。

下面一一说明图中内容的含义：

如上图中箭头所指向位置，在这里使用同步方式还是使用异步方式。从这两种方式产生的问题角度入手分析他们的优缺点：

不管同步还是异步都有可能造成 缓存击穿 问题，所以更新缓存的过程中最好进行一些排他动作以防止洪泛的发生。

主动更新、被动更新这些技术适应于不同的场景。它们各自有各自的优缺点，在技术设计阶段需要考虑实际的业务场景来决策到底使用那种方式合适。这个很多时候是需要设计人员的经验来进行决策。所以，任何一种软件设计过程都是一个决策和权衡的过程。

使用缓存的目标就是： 通过减少对慢速服务的访问，来提速 。所以在实际的缓存环境中，最主要的目标是减少访问慢速来达到使用缓存提速的目标。而在这个过程中可以使用的整体方案很多，可以通过不同事项的调整来完成自己的方案。

浅谈 Cache

如何设计实现真正的响应式微服务系统

一、清晰轻量的产品逻辑

奥卡姆剃须刀法则同样在产品架构设计中适用，越简单的架构越有利于产品的生长。清晰轻量的产品逻辑，会减少用户的负担感，从而提高交互上的效率和愉悦感。

分析MaterialDesign，会发现Google归纳了两类复杂内容信息的层级关系，分别是Card和Tile（List

以及其他相似定义属于同类的内容信息层级），其他定义多用于UI结构及细节。其中，Google定义Card是一种多功能信息的聚合入口，信息层级应较

高，体现在Z轴应高于其他信息，视觉上有阴影表现并加以圆角处理。而tile（或同类信息列表）则是（同类或相关）信息的模块展现，信息层级应较低，体现

在Z轴应略低于其他信息，视觉上应无阴影表现不加圆角处理。其结果是从视觉层面让产品对象更高效、更简单，同时也更具物理世界的“真实感”。

最近接手的项目是Gekec.com的全站改版。Gekec（革客）是Geek和Maker交集，喜欢革新，喜欢技术范儿、新潮的科技消费品，喜欢

自己动手创造产品，Gekec.com也就是这类人的聚集地，整个产品囊括电商、资讯（或h5宣传）、拆机、以及社区讨论等各种功能，改版前逻辑复杂，功

能繁多。改版开始之初，笔者了解到革客群体时，便认为理性加浓重Geek味道的Google风格或许是最适合Gekec.com的视觉体系，然而复杂的产

品逻辑不能给用户带来高效的交互体验和愉悦的使用感受，视觉上也并不能很好的通过Material

Design推演并且变化，所以梳理出清晰、轻量且方便视觉统一的产品逻辑成为第一任务。

Gekec.com的产品全功能在此并不赘述，ProctFeature全部为达成宜家式的体验式设计，经过梳理可以归纳成三层，首层为体验层（多入口的首页封面）、第二层为货架层（包括商城模块、拆机模块、体验模块）、第三层为详细、操作层；

如上图，轻量的产品结构即可方便设计的推演。例如其中第一层可以通过H5灵活排版做产品全方位体验，第二层与第三层的关系即可利用Material

Card和Tile表现。Card表达了全部信息的聚合和入口，tile则表现同类信息的罗列。从card跳转到最终页应有一种卡片展开的体验。

二、适宜UI推演的响应办法

在产品逻辑清晰简洁的基础上，一套适宜MaterialDesign变化的全尺寸响应办法就成为复杂响应式网页设计的核心内容，响应办法能够直接决定功能模块的响应逻辑以及UI的变化。实际操作中，响应办法的确定主要就是确定栅格和占比。

1）栅格

网页栅格系统是从平面栅格系统中发展而来。对于网页设计来说，栅格系统的使用，不仅可以让网页的信息呈现更加美观易读，更具可用性。而且，对于前端

开发来说，网页将更加的灵活与规范。栅格系统的具体含义以及使用方法在此不再赘述，感兴趣的朋友可以参考淘宝UED的一些文章：

网页栅格系统研究（1）：960的秘密

网页栅格系统研究（2）：蛋糕的切法

网页栅格系统研究（3）：粒度问题

网页栅格系统研究（4）：技术实现

在Gekec.com的项目中，经历产品功能模块的梳理，笔者使用了12栅格系统，目的是能够满足2、3、4、6的页面等分。注：具体栅格系统的建立应因产品和设计所决定，栅格系统并不是万能的，而确定的栅格系统可以为整个响应式设计做规范性参考。

2）占比

A.占比

如上文说，12栅格约束网页的内容区，而网页的内容往往并不占据屏幕的全部宽度，而是在两侧留有间隙，营造空间感。由于屏幕的限制，这种空间感在移动端设备显得更加重要，如图，然而强加固定的marginpixel会使得12栅格占比不定，难以控制设计效果。

所以占比应是12栅格宽度对应屏幕的比值，即：

12栅格宽度X占比=屏幕宽（临界点）

优秀而巧妙的占比确定可以让网页设计呈现在各个主流屏幕上均是100%像素。

这里简单解释一下，若一个200px宽的元素在1200px宽的屏幕上，其占比为16.67%，同样的逻辑，到1024px的屏幕上这个占比

16.67%的元素即占据了170.67px，这样的情况下，某一个物理像素无法占据100%，在完美主义的设计师眼里，是无法接受的事情。而巧妙的占

比，可以让元素在各个主流屏幕占据100%像素，完美展现设计意图。

B.临界点

临界点（breakpoint）是指响应式网页发生布局变化的关键点，如“当屏幕宽度小于480px时加载...样式，当宽度在480px-

600px之间时加载样式”。响应式网页理论上有无数种尺寸，我们不可能也没有必要为每个尺寸都去做设计，需要做的是选定几个临界点做设计，在两个临界

点之间是延续上一个临界点的布局。

临界点确认总体目的就是为了保证页面在手机（屏幕很小）、平板（屏幕中等）、PC（屏幕大）上加载相应的样式，然而经验较少的设计师往往会苦恼一个

问题，那就是高像素的手机屏幕和低像素的平板屏幕应如何处理。例如设计师会担心1080p的手机加载大屏幕页面，或者720p的平板加载小屏幕页面。

但需要注意的是，响应式网页不同于APP的屏幕适配。网页是沉浸于浏览器的产品，浏览器所启动的屏幕像素才可以被认为是临界点的参考点，为此，笔者

做了一些测试，如下表，可以看出不少1080p手机在浏览器中仅启动360px，而神奇的ipad无论是不是retina屏幕，无论是不是mini，均显

示1024x768px。

1.微服务管理-17.用户管理-0.概述

微服务实践目录 ，可以参见连接。

对于软件系统来说不管以怎样的形式服务于人，最终都是为了人们更舒适，更便利，更高效的生活而出现的。所以，对于软件系统来说识别出用户，并给用户提供相关的便利就是软件系统的最终目标。

对于人们直接能看到的软件系统，人们能直接感觉到软件系统再对其进行识别和认证的工作。但有很多软件系统是一般的用户看不到的，这些系统里面也有认证不过人们不关心。例如：在使用Wifi的时候，显示的需要知道Wifi的密码才允许登录，隐式的需要IP才能够进行通信。那DHCP系统是不是需要对设备进行认证，认证过程是什么样的？

在显示生活中有很多类似的例子，再比如：打电话的时候我可以通过电话号码知道对方是谁，但是通话过程中通信的链路是怎样建立起来的，这中间是不是有认证的过程，是不是有授权的过程，是不是有计费的过程？

这些就是软件在用户不感知或无法感知的情况下对用户进行了识别与认证的工作。并未客户提供了服务。这就是用户管理的意义。

在用户管理的过程中 AAA 是用户管理的重中之重。我们也会对AAA进行大概的介绍。但除了AAA之外还有一部分比较重要的内容：用户会话管理。用户会话管理主要是技术上的实现，跟最终用户的关系不太大或者最终用户看不到。所以，在进行用户管理时一般向用户展示的内容提到级别比较高，用户注意不到的内容就省略了。

大概说明这四个部分的关注点：

在上面所介绍的用户管理四部分中，每一个部分都可以独立于其他部分独立使用。现在业界有很多独立的解决方案出现。有专门负责认证部分的SSO，有专门负责鉴权的Apache Shiro，有专门负责计费的PAAS计费系统。也有很多联合技术，例如OpenAPI系统的用户管理，鉴权，计费的处理。

对于不同的使用场景来说，独立使用四部分中的一部分还是联合使用其中的几部分都是需要根据具体的使用场景进行分析与设计的。为了更清晰的介绍四部分，下面会具体的介绍着四部分。并且会在之后连续的几篇文章中深入的介绍每一个部分。

对于软件系统来说，外部所有的利益相关者都是需要定义出来的。那对于用户管理系统的用户的定义具体是什么样的？可以使用一个更加能够体现出它的特点的词语： 认证实体 来表示。

那么定义出用户管理系统的用户之后，那就定义认证过程的动作。认证过程就是通过验证认证实体的某些信息达到认为《认证实体》是软件系统中存在的《认证实体》的目的。

软件业界用户认证思路：

对于通过认证的认证实体来说，认证实体使用软件系统中的某个服务。系统需要判断认证实体是否对这个服务有操作权限，数据是否允许被访问等。更有甚者，对用户的服务级别都有定义。例如：

对于权限控制比较重要的两项：

现在很多互联网企业都对C端用户实行免费使用政策。采用B2C或者融合后的B向C提供服务都是需要一个收费模式的。

在很多Iaas，Paas，Saas中最常采用的计费方式是租户计费方式，而像印象笔记，Processon等直接面对C端用户的更长采用的用户计费模式。

前两种都是比较常见的。资源计费在用户使用资源时才会计费，这是云基础设施推出时的目标。服务质量计费可以简单的理解为京东Plus会员，电信服务商提供的带宽。

会话保持，会话保存，会话记录都是会话管理需要管理的内容。它们每个项可以在不同的领域发挥作用。

接下来几篇文章我们会先讨论用户管理的内容，然后在进行用户管理的一些技术实践。在实践中介绍各种技术的不同点，方便之后在实际项目中选用。

AAA

RBAC

RADIUS portal认证 TACACS+ Diameter LDAP Kerberos