随笔分类 - 成为架构师
摘要：成为一个合格的架构师，一定会面临以下九大场景，80个架构问题。画外音： （1）文章较长，建议收藏； （2）文章底部有视频版本； 【第一章：技术选型】 创业初期架构方案怎么选型？ （1）要考虑业务的需求与特点，初期往往“快速实现”更重要，此时系统的特点是请求量小，数据量小，服务器资源也非常有限； （2
阅读全文
摘要：我的分离目标是什么？ 最低目标：让大家了解，架构设计主流方法论，行业的经典实践、 中级目标：做相关设计时，方向不要跑偏 最好能够：拿回去，立刻能解决工作中的问题 我的架构理念是什么？ （1）架构，是能支持“高质，高效，快速，安全，低成本”系统交付的设计方法 （2）任何脱离业务的架构设计都是耍流氓 （
阅读全文
摘要：什么是耦合？ 不该联动，因为各种原因，绑在了一起。 系统联动，系统耦合，是架构大乱。 如何找到耦合？ 查询“被动联动”的地方。 每当心中怒骂“MD，明明和我无关，为何我要配合”的地方，就是耦合。 配置私藏 全局配置文件 配置中心，解耦利器：逻辑上解耦，物理上连接 MQ，解耦利器：逻辑上解耦，物理上解
阅读全文
摘要：总结： 一、先迁移站点层、业务服务层和基础服务层 （1）准备新机房与专线； （2）搭建集群，充分测试，子业务垂直拆分迁移； （3）灰度切流量； 二、缓存层迁移 （1）搭建新缓存； （2）运维修改缓存内网DNS，切断旧缓存连接，重新连接新缓存，切流量； 三、数据库迁移 （1）搭建新数据库； （2）同步
阅读全文
摘要：总结 （1）单机房架构：全连接 （2）理想多机房架构：同连接（适用于能按照业务进行数据分割的场景） （3）拆衷多机房架构：最小化跨机房连接（通用）
阅读全文
摘要：ServiceMesh-lstio总结 （1）二层架构 （2）五大模块 •数据平面，主要负责高效转发 （1）envoy模块：即proxy; •控制平面，主要负责控制与应用 （2）mixer模块：支持跨平台，标准化API的adapter; （3）pilot模块：控制与配置envoy的大部分策略; （4
阅读全文
摘要：总结 （1）分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！ （2）架构分层方法论： --让上游更高效的获取与处理数据，复用 --让下游能屏蔽数据的获取细节，封装 （3）业务的归业务，技术的归技术，服务网络（ServiceMesh），本质也是分层解耦
阅读全文
摘要：总结 （1）分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！ （2）架构分层方法论： --让上游更高效的获取与处理数据，复用 --让下游能屏蔽数据的获取细节，封装 （3）为了屏蔽数据库层面的复杂性，需要数据库中间件
阅读全文
摘要：总结 （1）分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！ （2）架构分层方法论： --让上游更高效的获取与处理数据，复用 --让下游能屏蔽数据的获取细节，封装 （3）为了屏蔽端上多变，PC/H5/APP等产品复杂性，需要引入前后端分离
阅读全文
摘要：总结 （1）分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！ （2）架构分层方法论： --让上游更高效的获取与处理数据，复用 --让下游能屏蔽数据的获取细节，封装 （3）为了屏蔽多个基础服务的调用，需要引入业务服务层
阅读全文
摘要：总结 （1）分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！ （2）架构分层方法论： --让上游更高效的获取与处理数据，复用 --让下游能屏蔽数据的获取细节，封装 （3）为了屏蔽数据库数据细节，需要引入DAO （4）为了屏蔽垂直拆分，分库分表，缓存细节，需要基础数据服务化分层
阅读全文
摘要：总结 （1）分层架构，是一个“数据移动”，然后“被处理”，被“呈现”的过程！ （2）数据移动的过程中，以下两点尤其重要： --数据传输的格式 --数据在各个层次的形态 （3）架构分层方法论： --让上游更高效的获取与处理数据，复用 --让下游能屏蔽数据的获取细节，封装
阅读全文
摘要：如何解耦？ 个性化代码上浮，通用代码下沉，服务化更彻底！ 总结与启示 （1）讨论技术方案时，不要总以： “放在你那边做代码少” “放在你那边做时间短” 作为设计折衷的理由，而要多问： “怎么做合理” （2）尽量杜绝底层出现 switch case (biz_type) 走不同分支的代码。 （3）个性
阅读全文
摘要：方案对比 解耦之前： 解耦之后： （1）代码简单，一次数据库访问 （1）代码更复杂，多次数据库访问 （2）逻辑实现在SQL里 （2）逻辑实现在服务层 （3）数据库耦合 （3）数据库解合 达到效果：给机器就能扩容！ 总结 场景三：“数据库耦合”如何解耦？ 第一步：公共数据访问服务化，数据私藏 第二步：
阅读全文
摘要：总结 如何发现系统中的耦合？ 查找“被动联动”的点。 场景一：“IP耦合”如何解耦？ 使用内网域名来替代内网IP。 场景二：“公共库耦合”如何解耦？ 粗暴方案：代码各自拷贝一份。 优化方案： （1）垂直拆分，个性业务代码“上浮” （2）服务化，共性业务代码“下沉”
阅读全文
摘要：总结 MQ是一个互联网架构中常见的解耦利器。 如何实现MQ的平滑迁移？ 步骤一：消费方双向订阅； 步骤二：生产方升级为新发布； 步骤三：消费方下线旧订阅； 如何快速实现统一迁移？ 浅浅的封装一层
阅读全文
摘要：总结 MQ是一个互联网架构中常见的解耦利器。 什么时候不使用MQ？ 上游实时关注执行结果，通常采用RPC。 什么时候使用MQ？ （1）数据驱动的任务依赖。 （2）上游不关心执行结果。 （3）上游关注结果，但执行时间很长。 （4）削峰填谷，流量控制，保护下游。
阅读全文
摘要：总结 有什么核心痛点？ （1）上游痛： 扩容的是下游，改配置重启的是上游（耦合，典型反向依赖） （2）下游痛： 不知道谁依赖于自己（难以实施服务治理） 怎么解耦，怎么解决？ （1）“配置私藏”架构 （2）“全局配置文件”架构 （3）“配置中心”架构
阅读全文
摘要：千万流量，要玩好服务化，数据库，缓存
阅读全文
摘要：总结 什么时候选redis？ （1）复杂数据结构 （1）持久化 （1）天然高可用 （1）存储内容比较大 什么时候选memcache？ 纯KV 为什么mc在纯KV能更快呢？ （1）预分配内存池 （1）redis的VM机制更慢 （1）redis的CPU计算复杂 （1）多线程可利用多核 其他 （1）red
阅读全文
