软件架构阅读笔记15
背景：
话费充值业务线的订单量也‘水涨船高 ’，同时对系统的各项运行指标要求更高，老的系统架构不足以支撑新的业务量，需要对系统进行升级。
1、应用层面
引入缓存
在应用层和数据库层增加缓存层：热点数据放入缓存。
编写并发处理程序：多任务并发处理，充分利用CPU资源。无依赖关系的多条任务可以并行处理，提高系统处理能力。
系统结构优化：
核心生成流程异步处理，接收用户订单和给用户充值两个流程异步化处理，提高系统处理能力。拆解大应用，使其微服务化。应用拆解为PC端、Server端、MQ消息处理端、后台管理端、worker端等五个应用
应用之间功能独立，依赖公司的RPC框架（JSF）和消息框架（JMQ）进行通信。单个应用的内聚性更高，应用之间的耦合度更低。再实现一个后台的需求时，开发、测试、部署都只需要关注后台管理端系统即可，无需再关注其他四个系统。
系统微服务化设计，关键点是如何寻找限界。除了可以从功能上进行切分还可以根据关注点上进行拆解为生产端和支撑端，业务场景不同，寻找限界的方法也不相同，关键是微服务后单个应用的内聚性更高，应用之间的耦合度更低。
使大系统微服务化的方案有很多种，重点是制定好目标，逐步向目标靠拢。
读写分离
实时性要求不高的数据读取从库，降低主库压力。
变化频率低的页面静态化
页面上的数据变化的只有广告位。这种类型的页面就可以静态化，定时更新页面，推送到存储介质上，nginx配置location，直接读取页面，降低后端服务的压力。
2. 数据库层面（当业务量发展到一定程度后，数据库就会成为系统的瓶颈）
话费充值应用包含企业订单业务和普通用户订单业务，正是由于其业务的特殊性，采用了垂直+水平分库方案。根据业务类型进行垂直切分，不同业务类型订单数据独立存储，同一种业务类型在水平上由多个库保存。垂直+水平的分库方案能够最大限度的降低不同业务类型订单数据之间的相互影响，提高数据读写并发量。
普通用户订单业务，根据账户PIN进行hash打散可以均匀的分布到每个库中.
企业订单业务，每个企业账户的订单量不均，根据本地订单号进行hash，然后再作为本地订单号的前缀。创建ERP订单成功后，同样需要保存本地订单号和ERP订单号的映射关系到JmiDB中，以保证在后续的业务流程中，能够根据ERP订单号路由到数据库。
拆分完成后，有的业务场景需要聚合查询数据。通用的聚合方案是从每个库中查询一页数据，在内存中根据条件排序，返回一页数据，如果需要翻页的话，逻辑更为复杂。话费充值应用采用了第三方存储，把每个分库中的订单数据聚合到ElasticSearch中，查询聚合数据的场景读取ElasticSearch。
通用的聚合方案是从每个库中查询一页数据，在内存中根据条件排序，返回一页数据，如果需要翻页的话，逻辑更为复杂。话费充值应用采用了第三方存储，把每个分库中的订单数据聚合到ElasticSearch中，查询聚合数据的场景读取ElasticSearch。
3应用部署
计算机资源的隔离显得尤为重要，在JVM内部隔离分为信号量隔离和线程池隔离，Netflix Hystrix插件提供了完美的支持。JD-Peer（多机房公网出口路由系统）中使用了Hystrix对每一个商家进行了隔离。
版本发布
灰度发布，平滑过渡，异常情况下的版本回滚，要确保回滚前的数据在老版本中可用。在保证系统服务正常可用的情况下，进行上述一系列的升级。
