上四节讲述了传输层，存储层，计算层，工具层本节介绍最后一层服务层
服务层这层算是最贴近业务的核心服务层了，不管大公司还是小公司，都会在上面有所建树
一、智能缓存
这里主要讲以下几点：
缓存能解决哪些问题？缓存技术都有哪些？缓存行业服务商都有哪些？1.缓存能解决的问题
性能——将相应数据存储起来以避免数据的重复创建、处理和传输，可有效提高性能。比如将不改变的数据缓存起来，例如国家列表等，这样能明显提高web程序的反应速度；稳定性——同一个应用中，对同一数据、逻辑功能和用户界面的多次请求时经常发生的。当用户基数很大时，如果每次请求都进行处理，消耗的资源是很大的浪费，也同时造成系统的不稳定。例如，web应用中，对一些静态页面的呈现内容进行缓存能有效的节省资源，提高稳定性。而缓存数据也能降低对数据库的访问次数，降低数据库的负担和提高数据库的服务能力；可用性——有时，提供数据信息的服务可能会意外停止，如果使用了缓存技术，可以在一定时间内仍正常提供对最终用户的支持，提高了系统的可用性。1）理解状态在深入介绍缓存技术之前，需要对状态有一个认识，因为缓存可以说是状态管理的框架。理解状态的含义和它的一些特性——比如生存期和生存范围——对决定是否缓存和选择合适的缓存技术有很大帮助。状态是指一些数据，在应用系统某个时间点上，数据的状态和条件。这些数据可能是永久性的存储在数据库中，可能是只在内存里停留一会，也可能是按照某个逻辑存活（比如多长时间后释放），它的应用范围可能是所有用户可访问，可能是单个用户有权限；
2）状态的生存期
生存期是指数据保持有效性的时间区间，也就是从创建到移除的时间间隔。通常的生存期有以下几种：
永久状态PermanentState——应用程序使用的永久数据；进程状态ProcessState——只在进程周期内有效；会话状态SessionState——和特定的用户会话有关；消息状态MessageState——处理某个消息的时间内有效；3）状态的范围状态的范围指对该状态有访问权限的物理或逻辑范围。
物理范围指可以被访问到的状态数据存放的物理位置，通常包括：①组织Organization——在一个组织内的所有应用程序可以访问状态数据；
②场Farm——在应用场范围内的任何机器上都可以访问；
③机器Machine——单个机器范围内可以访问；
④进程Process——进程内的访问许可；
⑤应用域AppDomain——应用程序域内的访问许可。
逻辑范围指可访问状态数据的逻辑范围，常见的有：①应用程序Application；
②业务流程BusinessProcess；
③角色Role；
④用户User；
4）状态数据的陈旧
缓存的状态数据只是主数据（MasterStateData）的快照，由于数据源可能被修改，所以状态数据就有会陈旧的特性。合理利用此特性和将数据陈旧的负面影响最小化是缓存状态数据的一个重要任务。你可以以一下方式定义数据的陈旧依据：
主数据更改的可能性——随着时间的推进，主数据更改的可能是否大大增加？安照这一点来决定缓存状态数据的陈旧；更改的相关性——主数据更新时，缓存的状态数据不相应更新是不是造成影响系统的使用？比如，更改系统的外观风格并不会对业务造成很大影响。5）状态数据陈旧的容忍度缓存状态数据的陈旧对业务流程的影响称为容忍度，应用系统的可以为不能容忍(NoTolerance)和一定程度的容忍(someTolerance)，前者必须和主数据同步更新，后者允许一定时间或一定范围的陈旧，判断标准就是对业务流程的影响度。
6）理解状态数据的转换过程
状态的另一个属性是在不同阶段的表现形式。在数据库中存储的是原始格式的数据，业务流程中的是处理过的数据，给最终用户呈现的则是另外的形式。如下表所示：
理解状态数据的转换过程当决定缓存数据时，应该考虑缓存哪个阶段（哪种形式）的状态数据。以下方针有助于你做决定：
当业务逻辑可以容忍缓存数据的陈旧时就缓存原始数据；原始数据可以缓存在数据库访问组件和服务代理中；缓存处理过的数据以减少处理时间和资源；处理过的数据可以缓存在业务逻辑组件和服务接口中。7）为什么要缓存数据
在应用程序中缓存数据有以下好处：
减少交互的通讯量——缓存数据能有效减少在进程和机器间的传输量；降低系统中的处理量——减少处理次数；降低需要做的磁盘访问次数——比如缓存在内存中的数据。8）数据应该被缓存在哪里
缓存数据只是一份主数据的拷贝，它可能在内存中或以不同的表现形式保存在硬盘上，也就是说，离说句的使用者越近越好。所以，除了考虑要缓存哪些数据以外，数据缓存在哪里也是一个主要的考量点。这个问题分为以下两个范围：
①存储类型StorageType——数据可用的物理存储位置；
②层间的架构元素（Layeredarchitectureelements）——数据可用的逻辑存储位置。
9）存储类型
缓存有很多实现方法，所有这些可以被分为两类，基于内存的缓存和基于磁盘的缓存：
①内存驻留缓存——包含在内存中临时存储数据的所有实现方法，通常在以下情况下使用：
a)应用程序频繁使用同样的数据；
b)应用程序需要经常获取数据；
通过将数据保留在内存中，你可以有效降低昂贵的磁盘访问操作，也可以通过将数据保留在使用者进程中来最大程度的减少跨进程的数据传输。
②磁盘驻留缓存——这种技术包含所有使用磁盘作为存储介质的缓存技术，如文件和数据库。在以下情况下基于磁盘的缓存是很有效的：
a)处理大数据量时；
b)应用服务提供的数据可能并不是总能使用（比如离线的情况）；
c)缓存的数据必须能在进程回收和机器重启的情况下保持有效；
通过缓存处理过的数据，你可以有效降低数据处理的负担，同时可减少数据交互的代价。
2.缓存技术都有哪些？
说起缓存相关技术，老多了，memcache、redis、squid、varnish、webcache、CDN等等。缓存技术五花八门，但这些技术间有什么共性的地方，又有什么不同的地方呢？答案肯定是有的，这次为大家分享及整理一下缓存方面的技术，主要分为三个系列展开：
数据库缓存静态缓存动态缓存数据库缓存
1）什么是数据库缓存
我们知道常见的数据库，比如oracle、mysql等，数据都是存放在磁盘中。虽然在数据库层也做了对应的缓存，但这种数据库层次的缓存一般针对的是查询内容，而且粒度也太小，一般只有表中数据没有变更的时候，数据库对应的cache才发挥了作用。但这并不能减少业务系统对数据库产生的增、删、查、改的庞大IO压力。所以数据库缓存技术在此诞生，实现热点数据的高速缓存，提高应用的响应速度，极大缓解后端数据库的压力。
以下为memcache数据库缓存为例，以图说明一下什么是数据库缓存：
memcache架构2）数据库缓存的技术特点
性能优越数据库缓存的第一个技术特点就是提高性能，所以数据库缓存的数据基本上都是存储在内存中，相比io读写的速度，数据访问快速返回。而且在mysql5.6的版本开始，已经把memcache这种跟数据库缓存直接挂钩的中间件直接集成进去了，已经等不及我们自己去单独部署对应数据库缓存的中间件了。
应用场景针对数据库的增、删、查、改，数据库缓存技术应用场景绝大部分针对的是“查”的场景。比如，一篇经常访问的帖子/文章/新闻、热门商品的描述信息、好友评论/留言等。因为在常见的应用中，数据库层次的压力有80%的是查询，20%的才是数据的变更操作。所以绝大部分的应用场景的还是“查”缓存。当然，“增、删、改”的场景也是有的。比如，一篇文章访问的次数，不可能每访问一次，我们就去数据库里面加一次吧？这种时候，我们一般“增”场景的缓存就必不可少。否则，一篇文章被访问了十万次，代码层次不会还去做十万次的数据库操作吧。
数据一致性在很多应用场景中，当一个数据发生变更的时候，很多人在考虑怎么样确保缓存数据和数据库中数据保存一致性，确保从缓存读取的数据是最新的。甚至，有人在对应数据变更的时候，先更新数据库，然后再去更新缓存。我觉得这个考虑不太现实，一方面这会导致代码层次逻辑变得复杂，另外一方面也真想不明白还要缓存干什么了。在绝大多数的应用中，缓存中的数据和数据库中的数据是不一致的。即，我们牺牲了实时性换回了访问速度。比如，一篇经常访问的帖子，可能这篇帖子已经在数据库层次进行了变更。而我们每次访问的时候，读取的都是缓存中的数据（帖子）。既然是缓存，那么必然是对实时性可以有一定的容忍度的数据，容忍度的时间可以是5分钟，也可以是5小时，取决于业务场景的要求。相反，一定要求是实时性的数据库，就不应该从缓存里读取，比如库存，再比如价格。
高可用自从有了缓存，代码每天快乐的去缓存中愉快的玩耍。为什么说高可用呢，我们知道缓存为数据库抵挡了很多压力，同时也为应用提供了良好的访问速度。但同时有没有想过缓存的感受，如果当数据库缓存“罢工”了，这会出现什么后果？特别在一些高并发的应用中，数据库层肯定是“消化不良“，最终导致应用全面崩溃。所以缓存的高可用显得非常重要。
3）数据库缓存常见开源技术
要说用于数据库缓存场景的开源技术，那必然是memcache和redis这两个中间件。因为都是专注于内存缓存领域，memcache和redis向来都有争议。比如性能，到底是memcache性能好，还是redis性能更好等。同样都是内存缓存技术，它们都有自己的技术特性。没有更好的技术，只有更合适的技术。个人总结一下，有持久化需求或者对数据结构和处理有高级要求的应用，选择redis。其他简单的key/value存储，选择memcache。所以根据自身业务特性，数据库缓存来选择适合自己的技术。
各种缓存技术对比静态缓存
说起静态缓存技术，CDN是经典代表之作。静态缓存技术面非常广，涉及的开源技术包含apache、Lig