中小企业的架构之道

为什么要谈中小企业的架构之道

--------------------------------------------------

所有的大公司都是从中小型企业发展起来的

如果经的创业环境下中小企业是大多数

中小企业的it现状堪忧

当业务变化时打了太多的补丁程序

当业务发展时系统不断出现各种瓶颈

1、系统出现各种故障、卡顿

2、数据库经常锁死

3、用户法宁网站打不开

4、业务团队或者老板抱怨一搞活动系统就挂掉



谈谈中小企业的现状

--------------------------------------------------

技术团队人数不超过50人

硬件数量20-30台服务器&＃xff08;不同批次、不同品牌&＃xff09;

带宽出口100Mbits&＃xff08;估计也就10Mbyte每秒&＃xff09;

项目耦合度搞&＃xff08;一个站点涵盖了几乎大多数功能&＃xff09;

数据库集中&＃xff08;可能没有主从备份、没有读写分离&＃xff09;

网上看到的bat的技术架构根本无法简单复制

1、部署成和时间严重不足

2、现有代码重构量大

3、技术人员承载力不足



我们应该如何应对&＃xff1f;##########

我们的武器库有哪些常规武器

--------------------------------------------------

数据库

1、主从复制

2、读写分离

3、分库分表

4、KV数据库

5、内存数据库

运维层面

1、静态资源分离

2、外部图片缓存

3、Nginx反向代理

4、Docker容器化

5、引入云的伸缩方案

6、负载均衡器

技术改造



内存数据

静态资源分离

消息机制与解耦



谈谈内存数据库

--------------------------------------------------

Redis特别推荐

1、稳定&＃xff0c;只要没有内存用满&＃xff0c;长时间稳定运行

2、性能出色&＃xff0c;单节点轻松承载每秒数千次访问

3、集群&＃xff0c;在3.0以后支持集群&＃xff0c;容量不再受到局限

4、安全&＃xff0c;支持主从、包括一写多读的链条状



Memcached

1、作为缓存性能出色

2、有数据量限制

3、自动淘汰数据



再说说静态资源分离

--------------------------------------------------

故事 or 事故

a、有了微信公众号&＃xff0c;已推送活动网页就打不开了&＃xff1b;

b、发现我们的出口140Mbps的带宽全满了

c、我们把活动页面里面的图片和js都放到CDN上

d、单量迅速恢复、后续每周活动都在提升



后续改进

1、使用xx来存放商品以及活动的图片跟js文件

2、开发了专门的服务控制所有前后台图片上传直接到cdn上



静态资源分离的本质是流量成本的精细化管理

1、带宽成本

2、业务站点服务器的计算资源成本

3、资源存储的成本



最后讲讲消息机制与解耦

--------------------------------------------------

中小企业面对主要挑战

1、大访问量&＃xff0c;峰谷比高&＃xff0c;成本压力大

2、业务复杂度&＃xff0c;模式太多&＃xff0c;请求耗时长

3、故障排查与监控



解决方向

1、伸缩性要强

2、逻辑解耦



回忆下生产者消费者模式

--------------------------------------------------

三个要素

a、生产者&＃xff08;Producer&＃xff09;

b、队列&＃xff08;Queue&＃xff09;

c、消费者&＃xff08;Consumer&＃xff09;



在架构中使用

a、产生事件的服务&＃xff08;Event&＃xff09;

b、消息队列&＃xff08;MessageQueue&＃xff09;

c、处理消息的服务&＃xff08;Handler&＃xff09;



什么是消息机制

--------------------------------------------------

定义消息

|-消息ID&＃xff0c;不重复

|-消息名称&＃xff0c;区分不同的消息

|-消息体&＃xff0c;数据



订阅者

|-不同订阅者

|-订阅者的副本数量



生产者

|-同一个语义只发一个消息

|-消息数据完整



MessageQueue产品

1、MSMQ

2、RabbitMQ Erlang

3、ActiveMQ java主流

4、RocketMQ taobao开源

5、MQS阿里云

6、SQS aws



如果我们不希望那么重&＃xff0c;可以基于redis自己写一个

a、消息用kv存储

b、消息id放在队列里



增加订阅者副本来伸缩

--------------------------------------------------

我们说到了提高系统的伸缩性

1、当系统压力增加的时候&＃xff0c;我们可以轻松通过增加订阅者的副本数量来增加处理能力

2、善用云服务来提供处理能力&＃xff0c;做到快速伸缩

3、有条件可以使用docker减少部署的成本

4、对于可以降级的服务&＃xff0c;运用Queue的存储能力来缓冲



服务拆分的无状态的重要性

--------------------------------------------------

意义和优点

1、没有上下午依赖&＃xff0c;每个消息都是独立的&＃xff1b;

2、经量不依赖本地配置或者资源

3、顺序无关性

4、可随时redo



应对必不可少的公共资源

--------------------------------------------------

a、线程安全

b、数据库访问&＃xff0c;要考虑性能

c、避免各种硬件、系统资源



业务场景

--------------------------------------------------

场景一

业务需求

登录

a、风控黑名单

b、业务数据统计

c、用户成长体系



场景二

业务需求

支付

a、支付成功&＃xff0c;接到银行callback

|-update payment status

|-callback bizsystem

|-statistics



在支付场景很常见

其实与外部系统的一些状态同步中都很常用

还可以跟schedule服务一起联动



场景三

业务需求

数据库更新

|-update cache

|-duplicate to remote storage



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



还有哪些需要注意的&＃xff1f;



注意事项

--------------------------------------------------

1、通常消息是无序的&＃xff0c;有序可以做成本搞

2、对于重要是消息要考虑MQ是否支持持久化

3、如果所有的订阅者都挂了&＃xff0c;MQ的存储压力

4、提防丢消息和重复消息

5、此模式下在scale时考虑运维的成本



分享一点架构观念

--------------------------------------------------

1、避免过度设计

2、始终保持精简&＃xff0c;精简才能灵活

3、知识积累很重要&＃xff0c;但是首先要解决问题。