Java高并发高性能分布式框架从无到有微服务架构设计

1、Java 高并发高性能分布式框架从无到有微效劳架构设计微效劳架构模式( Microservice Architect Pattern )。 近两年在效劳的疯狂增长与云计算技术的进步，让微效劳架 构受到重点关注 微效劳架构是一种架构模式，它提倡将单 一应用程序划分成一组小的效劳，效劳之间互相协调、互相 配合，为用户提供最终价值。每个效劳运行在其独立的进程 中，效劳与效劳间采用轻量级的通信机制互相沟通(通常是 基于 的RESTful API )。每个效劳都围绕着具体业务进 行构建， 并且能够被独立地部署到生产环境、 类生产环境等。 另外，应尽量防止统一的、集中式的效劳管理机制，对具体 的一个效劳而

2、言，应根据业务上下文，选择适宜的语言、工 具对其进行构建。微效劳架构优势 首先简单介绍了微效劳 (Microservices )的内涵及优势，微效劳架构的本质，是 用一些功能比拟明确、业务比拟精练的效劳去解决更大、更 实际的问题。微效劳架构将效劳拆分，分别采用相对独立的 效劳对各方面进行管理，彼此之间使用统一的接口来进行交 流，架构变得复杂，优势也很明显： 复杂度可控：在将应 用分解的同时，躲避了原本复杂度无止境的积累。每一个微 效劳专注于单一功能，并通过定义良好的接口清晰表述效劳 边界。由于体积小、复杂度低，每个微效劳可由一个小规模 开发团队完全掌控，易于保持高可维护性和开发效率。什么是微效

3、劳架构微效劳架构优势 独立部署：由于微效劳具备 独立的运行进程，所以每个微效劳也可以独立部署。当某个 微效劳发生变更时无需编译、部署整个应用。由微效劳组成 的应用相当于具备一系列可并行的发布流程，使得发布更加 高效，同时降低对生产环境所造成的风险，最终缩短应用交 付周期。 技术选型灵活：微效劳架构下，技术选型是去中 心化的。每个团队可以根据自身效劳的需求和行业开展的现 状，自由选择最适合的技术栈。由于每个微效劳相对简单， 当需要对技术栈进行升级时所面临的风险较低，甚至完全重 构一个微效劳也是可行的。 容错：当某一组建发生故障时， 在单一进程的传统架构下，故障很有可能在进程内扩散，形 成应用全局

4、性的不可用。在微效劳架构下，故障会被隔离在 单个效劳中。假设设计良好，其他效劳可通过重试、平稳退化 等机制实现应用层面的容错。 扩展：单块架构应用也可以 实现横向扩展，就是将整个应用完整的复制到不同的节点。 当应用的不同组件在扩展需求上存在差异时，微效劳架构便 表达出其灵活性，因为每个效劳可以根据实际需求独立进行 扩展。互联网高并发相关名词页面浏览数( page views ) 唯一身份浏览量( Unique PageViews )独立访问者数量 ( unique visitors )重复访问者数量( repeat visitors)每个访问者的页面浏览数( Page Views per us

5、er )高并发 之前我将高并发的解决方法误认为是线程或者是队列可以解决，因为高并发的时候是有很多用户在访问，导致出现系 统数据不正确、丧失数据现象，所以想到 的是用队列解决， 其实队列解决的方式也可以处理，比方我们在竞拍商品、转 发评论微博或者是秒杀商品等，同一时间访问量特别大，队 列在此起到特别的作用，将 所有请求放入队列，以毫秒计 时单位，有序的进行，从而不会出现数据丧失系统数据不正 确的情况。 经过查资料，高并发的解决方法有俩种，一种 是使用缓存、另一种是使用生成静态页面；还有就是从最基 础的地方优化我们写代码减少不必要的资源浪费： 1. 不要 频繁的new对象,对于在整个应用中只需要存

6、在一个实例的 类使用单例模式 . 对于 String 的连接操作 , 使用 StringBuffer 或者 StringBuilder. 对于 utility 类型的类 通过静态方法来访问。 2. 防止使用错误的方式 , 如 Exception 可以控制方法推出 , 但是 Exception 要保存 stacktrace 消耗性能 , 除非必要不要使用 instanceof 做条 件判断，尽量使用比的条件判断方式.使用JAVA中效率高的 类, 比方 ArrayList 比 Vector 性能好。 高并发 - 需要解决 的问题一：应用缓存二： 缓存三：多级缓存四：池化五: 异步并发六：扩容七：队

7、列高并发 - 应用缓存堆缓存 使用 Java 堆内存来存储缓存对象。 使用堆缓存的好处是没有序列 化/ 反序列化，是最快的缓存。缺点也很明显，当缓存的数 据量很大时，GC 垃圾回收暂停时间会变长，存储容量受限于堆空间大小。一般通过软引用 / 弱引用来存储缓存对象， 即当堆内存缺乏时，可以强制回收这局部内存释放堆内存空 间。一般使用堆缓存存储较热的数据。有Guava Cache： 缓存和 ConcurrentMap 是非常相像的， 但是它们也不完全一样。 最根本的区别就是， ConcurrentMap 会持有所有添加的对象， 直到被显示的移除。而缓存为了限制其内存的使用，通常都 会配置成可以自动

8、的将对象移除。在某些情况下即使不自动 移除对象也是非常有用的，如 LoadingCache 它会自动加载 缓存对象。 Ehcache 3.x ：是一种广泛使用的开源 Java 分布 式缓存。主要面向通用缓存 Java EE和轻量级容器。它具有 内存和磁盘存储，缓存加载器 , 缓存扩展 , 缓存异常处理程序 , 一个gzip缓存servlet 过滤器，支持REST和SOAP api等特 点。 MapDB： mapdb 是一个内嵌的纯 java 的数据库，提供了 并发的HashMap TreeMap、Queue,可以基于堆外或者磁盘 来存储数据高并发 - 应用缓存堆外缓存 即缓存数据存储在 堆外内

9、存，可以减少 GC暂停时间堆对象转移到堆外，GC扫描和移动的对象变少 ,但是,读取数据时需要序列化 / 反 序列化,因此会比堆缓存要慢很多。有 Ehcache 3.x 、 MapDB 实现磁盘缓存即缓存数据存储在磁道上，在JVM重启时数据还存在的,而堆缓存 / 堆外缓存数据会丧失,需要重新加 载。有、MapDB实现分布式缓存 进程内缓存和 磁盘缓存，在多JVM实例的情况下，会存在两个问题：1、 单机容量问题；2、数据一致性问题多台 JVM实例的缓存 数据不一致怎么办？ ，这个问题不用纠结，既然数据允许 缓存，那么表示允许一定时间内的不一致，因此可以设置缓存 数据的过期时间来定期更新数据； 3

10、、缓存不命中时，需要 回源到DB/效劳请求多变问题：每个实例在缓存不命中的情 况下都会回源到 DB加载数据，因此多实例后 DB整体的访问 量变多了解决方法是可以使用如一致性哈希分片算法。因 此，这些情况可以考虑使用分布式缓存来解决。 可以使用 ehcache clustered 配合 Terracotta server 实现 JAVA 进程间分布式缓存。最好的方法是使用 redis 实现分布式缓 存。高并发- 缓存浏览器缓存是指当我们使用浏览器访 问一些网站页面或者 效劳时，根据效劳端返回的缓存 设置响应头将响应内容缓存到浏览器，下次可以直接使用缓 存内容或者仅需要去效劳端验证内容是否过期即可

11、。这样的 好处可以减少浏览器和效劳端之间来回传输的数据量，节省 带宽提升性能。 解决方法：内容不需要动态计算、渲染 等速度更快，内容越接近于用户速度越快。像 apache traffic server 、 squid 、 varnish 、 nginx 等技术都可以来 进行内容缓存。还有 CDN就是用来加速用户访问的：即用户 首先访问到全国各地的 CDN节点使用如ATS Squid实现， 如果CDN没命中，会回源到中央 nginx集群，该集群如果没 有命中缓存该集群的缓存不是必须的，要根据实际命中情况等决定，最后回源到后端应用集群。高并发 - 多级缓存 分布式缓存高并发 - 池化在应用系统开发

12、过程中，我们 经常会用到池化技术，如对象池、连接池、线程池等，通过 池化来减少一些消耗，以提升性能。 对象池通过复用对象 从而减少创立对象、垃圾回收 的开销。但是，池化不能太 大，太大会影响GC时的扫描时间。 连接池如数据库连接池、 Redis连接池、 连接池，通过复用 TCP连接减少创立和 释放连接的时间来提升性能。 线程池也是类似的，通过复 用线程提升性能。也就是说池化的目的就是通过复用技术提 升性能。高并发 - 扩容 1、读写别离：当数据库访问量还不是 很大的时候，我们可以适当增加效劳器，数据库主从复制的 方式将读写别离 2、垂直分区： 当写入操作一旦增加的时候， 那么主从数据库将花更多

13、的时间的放在数据同步上，这个时 候效劳器也是不堪重负的；那么就有了数据的垂直分区，数 据的垂直分区思路是将写入操作比拟频繁的数据表，如用户 表_user,或者订单表_orders,那么我们就可以把这个两个 表别离出来，放在不同的效劳器，如果这两个表和其他表存 在联表查询，那么就只能把原来的 sql 语句给拆分了，先查 询一个表，在查询另一个，虽然说这个会消耗更过性能，但 比起那种大量数据同步，负担还是减轻了不少； 3、水平分 区：但是往往事情不尽人意，可能采取垂直分区能撑一段时 间，由于网站太火了，访问量又每日100w, 下子蹦到了1000w,这个时候可以采取数据的进行别离，我们可以根据user 的 Id 不同进行分配，如采取 %2、 %10 形式，当然这种 形式对以后的扩展有了很