中小企业的架构之道

为什么要谈中小企业的架构之道
--------------------------------------------------
所有的大公司都是从中小型企业发展起来的
如果经的创业环境下中小企业是大多数
中小企业的it现状堪忧
当业务变化时打了太多的补丁程序
当业务发展时系统不断出现各种瓶颈
1、系统出现各种故障、卡顿
2、数据库经常锁死
3、用户法宁网站打不开
4、业务团队或者老板抱怨一搞活动系统就挂掉

谈谈中小企业的现状
--------------------------------------------------
技术团队人数不超过50人
硬件数量20-30台服务器（不同批次、不同品牌）
带宽出口100Mbits（估计也就10Mbyte每秒）
项目耦合度搞（一个站点涵盖了几乎大多数功能）
数据库集中（可能没有主从备份、没有读写分离）
网上看到的bat的技术架构根本无法简单复制
1、部署成和时间严重不足
2、现有代码重构量大
3、技术人员承载力不足

我们应该如何应对？##########
我们的武器库有哪些常规武器
--------------------------------------------------
数据库
1、主从复制
2、读写分离
3、分库分表
4、KV数据库
5、内存数据库
运维层面
1、静态资源分离
2、外部图片缓存
3、Nginx反向代理
4、Docker容器化
5、引入云的伸缩方案
6、负载均衡器
技术改造

内存数据
静态资源分离
消息机制与解耦

谈谈内存数据库
--------------------------------------------------
Redis特别推荐
1、稳定，只要没有内存用满，长时间稳定运行
2、性能出色，单节点轻松承载每秒数千次访问
3、集群，在3.0以后支持集群，容量不再受到局限
4、安全，支持主从、包括一写多读的链条状

Memcached
1、作为缓存性能出色
2、有数据量限制
3、自动淘汰数据

再说说静态资源分离
--------------------------------------------------
故事 or 事故
a、有了微信公众号，已推送活动网页就打不开了；
b、发现我们的出口140Mbps的带宽全满了
c、我们把活动页面里面的图片和js都放到CDN上
d、单量迅速恢复、后续每周活动都在提升

后续改进
1、使用xx来存放商品以及活动的图片跟js文件
2、开发了专门的服务控制所有前后台图片上传直接到cdn上

静态资源分离的本质是流量成本的精细化管理
1、带宽成本
2、业务站点服务器的计算资源成本
3、资源存储的成本

最后讲讲消息机制与解耦
--------------------------------------------------
中小企业面对主要挑战
1、大访问量，峰谷比高，成本压力大
2、业务复杂度，模式太多，请求耗时长
3、故障排查与监控

解决方向
1、伸缩性要强
2、逻辑解耦

回忆下生产者消费者模式
--------------------------------------------------
三个要素
a、生产者（Producer）
b、队列（Queue）
c、消费者（Consumer）

在架构中使用
a、产生事件的服务（Event）
b、消息队列（MessageQueue）
c、处理消息的服务（Handler）

什么是消息机制
--------------------------------------------------
定义消息
|-消息ID，不重复
|-消息名称，区分不同的消息
|-消息体，数据

订阅者
|-不同订阅者
|-订阅者的副本数量

生产者
|-同一个语义只发一个消息
|-消息数据完整

MessageQueue产品
1、MSMQ
2、RabbitMQ Erlang
3、ActiveMQ java主流
4、RocketMQ taobao开源
5、MQS阿里云
6、SQS aws

如果我们不希望那么重，可以基于redis自己写一个
a、消息用kv存储
b、消息id放在队列里

增加订阅者副本来伸缩
--------------------------------------------------
我们说到了提高系统的伸缩性
1、当系统压力增加的时候，我们可以轻松通过增加订阅者的副本数量来增加处理能力
2、善用云服务来提供处理能力，做到快速伸缩
3、有条件可以使用docker减少部署的成本
4、对于可以降级的服务，运用Queue的存储能力来缓冲

服务拆分的无状态的重要性
--------------------------------------------------
意义和优点
1、没有上下午依赖，每个消息都是独立的；
2、经量不依赖本地配置或者资源
3、顺序无关性
4、可随时redo

应对必不可少的公共资源
--------------------------------------------------
a、线程安全
b、数据库访问，要考虑性能
c、避免各种硬件、系统资源

业务场景
--------------------------------------------------
场景一
业务需求
登录
a、风控黑名单
b、业务数据统计
c、用户成长体系

场景二
业务需求
支付
a、支付成功，接到银行callback
|-update payment status
|-callback bizsystem
|-statistics

在支付场景很常见
其实与外部系统的一些状态同步中都很常用
还可以跟schedule服务一起联动

场景三
业务需求
数据库更新
|-update cache
|-duplicate to remote storage

我们用这个做了数据库异地复制

还有哪些需要注意的？

注意事项
--------------------------------------------------
1、通常消息是无序的，有序可以做成本搞
2、对于重要是消息要考虑MQ是否支持持久化
3、如果所有的订阅者都挂了，MQ的存储压力
4、提防丢消息和重复消息
5、此模式下在scale时考虑运维的成本

分享一点架构观念
--------------------------------------------------
1、避免过度设计
2、始终保持精简，精简才能灵活
3、知识积累很重要，但是首先要解决问题。