技术架构快速规划与落地-58到家

1.保证高可用解决方案：冗余和复制

保证站点应用的高可用，数据层的高可用（读库写库的可用，一主两从，），linux的高可用，缓存高可用

数据层的高可用分为读库和写库的高可用，互联网公司读库一般采用的是一主两从或一主三从，采用读写分离。当一个机器挂了，另外的机器仍然可以工作。写库一般是单点的。写库的高可用。从库变主库，一主多从的方式无法保证高可用。

两个写库，只有一个写库对线上提供服务，两个写库的数据是相互同步的，通过vip，通过keepid检测的方式同步。当一个写库当掉了，流量自动切换到另一台写库上，和ngnix的高可用原理是一样的。

2.服务化能解决的问题

1）代码拷贝

用户库，dao层,jdbc等代码

产生的问题：代码一变，多个拷贝处都得改

解决：将相同的代码抽象成函数和服务

2）复杂性扩散

流量很大，加从库，流量越来越大，读多写少用缓存（架构设计的原则）从库不行了，则用缓存。数据量大，加库，user库。原来一个user库，现在多个，代码修改

解决：服务化解决

3）库耦合

库兼容性问题，并发改库，容易出现合并问题

4）DB耦合

一台机器抗1万，两台机器抗2万。一起Join一个表，表放一个库才行

5）SQL质量无保证

SQL的质量必须控制在服务层，数据库必须由服务层私有，任何上游不能绕过服务层，去访问数据库

以上解决都是加一层服务层，cache，mongodb,sql,访问数据库都写在服务层里，上游只需调用该服务层，给一个id，服务层给一个user实体，不关心底层。服务层高可用，也可以是多份

服务层不会出现if 业务1，else 业务2  而是变成两次访问。如

互联网公司 先取uid,再取别的属性，在服务层拼装起来，返回。库 水平切分后，出现大量的单条数据访问，5ms返回，5次访问，总时间很小

3. 58到家的最佳实践

一个部门专门做统一的实践：

统一服务框架，统一监控，统一数据访问层，统一的调用链跟踪，统一的配置中心，统一的服务治理，统一的消息总线

1）配置管理

业务A,B，初期是配置私藏：公共配置Ip，域名，放在自己的应用配置中。配置域名，更换域名，所有上游需重启。问题：上游需重启，但不知道通知谁

配置服务升级：

公共的配置放在全局文件中，修改了后，最坏的情况，上游下次重启，可以获得最新的配置

再优化：

实现两个组件，可以使得上游不必关心上游配置的升级

组件1：

配置文件的监控组件，

根据修改时间，轮询。当发现修改了，进行配置文件回调

组件2：动态的连接池

当ip减少了，将原有的ip锁住，当原有的连接执行完，将此连接drop掉。当新增了两个IP，建立连接，建立完后，放开锁，将连接给上游服务

全局配置文件，上游不需要关心配置，但是还是不能解决谁依赖的配置文件

解决：配置中心

所有上游依赖配置中心，配置中心给userservice的域名，当配置修改了，配置中心反向通知上游

2）消息总线

提供者只发消息，提供端修改了代码，重新发送消息即可

3）监控平台

多维：机器、操作系统，进程、端口、JVM，日志，接口

解决的问题：系统有无问题

问题：访问不了

grep一下web，找服务方，数据库DBA

解决：

调用链

4）调用链

请求链跨进程

解决生成全局id,框架是我控制的，在协议层加一个requestId

时序标识

如何知道谁先访问，服务器的时间是不准的。前提框架统一，在协议中加一个sokect,用序号标识请求

深度标识

深度id来标识，在框架中加字段，和上方一样

数据收集