青龙系统发展历程
Paste_Image.png
青龙系统架构最佳实践
Paste_Image.png
高可用
-
合适的架构方案
前端应用系统，双机房集群部署，
后端数据库系统，主从模式，单个机房写入，备库在另一个集分行。主从切换，读库双机房部署。
分拣中心有本地服务器和操作人员设备，可以离线生产。 -
大系统小做，服务拆分
敏捷交付。
微服务不是银弹，拆分粒度达到优雅平衡。 -
并发控制，服务隔离
硬件级隔离，全部隔离，前端应用隔离。 -
灰度发布
按用户，区域发布。 -
全方位监控报警
技术层面：CPU，内存，磁盘，网络等监控。
业务层面：处理积压量，正常的业务量。
先于用户发现问题。 -
核心服务，平滑降级
观点：任何技术手段，不能保证100%可用。即使做到，其代价也是巨大的，不经济的。
青龙系统研发了离线生产系统。分拣中心有本地服务器和操作人员设备。
高性能
-
接口数据缓存化
缓存服务 + 应用内缓存 + redis消息通知 -
同步调用异步化
微服务特点，一个api会调用多个服务接口，QPS无法满足。
腾讯CTO Tony提出，即使支付这种服务，也有办法进行异步化。
工具支持，redis分布式调用系统
Paste_Image.png
数据一致性
-
实时&强一致场景
binlog读取，Kafaka作数据传输，Spark流式计算，ES数据存储。
传统ELT抽取方案，会频繁对生产数据库进行抽取，极大影响线上OLTP系统的性能。
不适合的案例：应用写数据库的同时，发送给消息，大数据及系统接受消息并处理。效率有问题，并且强一致性不能保证，消息系统会丢消息。
（评：采用6个9的消息系统，并且做好丢消息后的补救措施，这就是最终一致性的理念。作者举的案例在当时的情况下可能不合适，现如今都这么大家都这么多，并无不妥） -
实时&弱一致性场景
消息通知，允许丢消息。
使用方订阅消息，按照主键，如订单号，存储即可。 -
离线&强一致场景
大数据分析场景，也就是众多的离线报表模式
ETL，数据仓库等 -
离线&弱一致场景
抓取数据，日志分析。
统计趋势类应用。
利用空闲的计算资源，晚上空闲时来做。
Paste_Image.png
架构应针对具体应用场景，满足当前的业务需求。适当考虑两年的需求。
最合适的架构才是最好的，没有放之四海都是最好的架构设计。
不满足自己的应用场景，盲目照抄大公司的技术架构，显然是不合适的。
选择架构要谨慎，随着变的复杂，后续替换成本也很高。
用户体验
-
MVP原则
敏捷开发的迭代思路。
大项目进行拆解，核心需求，优先开发上线；再开发低优先级需求。 -
动态运营
上线后看具体数据，随时调整，直到符合用户需求。
转自：https://comet-project.gitbooks.io/cto-tech-manual/content/chapter2/lipengtao.html
网友评论