技术经验杂感

纯干货！

技术架构的演化跟人类的演化类似。

为了当时当地的变化而变化。

提纲

企业应用

架构方法

复杂度

程序员的修养

架构

企业应用

业务逻辑，处理能力，使用人数，稳定性，安全性，可维护，可扩展，协作开发...

架构的目标

正确，健壮，简单，需求响应，独立，可扩展，性能

架构的方法

平衡：时间/空间,成本/效率,高可用/高一致(依业务需求考虑)

拆分：大系统->小系统、大数据库->小数据库、大事务-> 小事务（幂等性，重试实现最终一致性）

数据库的拆分：数据分片、读写分离（数据库复制、缓存）

系统的拆分：

合并：

转化：推拉 同步 异步 并行串行 数据库查询 服务调用 服务调用 事件驱动

业务功能拆分成多个功能单一的模块（页面、作业、服务）

相关的业务组成一个域

不同的域相互独立，采用1事件驱动、2 API调用来交互

不使用分布式事务，通过唯一性实现幂等性，通过重试和失败点恢复快速的实现最终一致性

数据的修改由一个集中点（系统、域、VLAN、团队）控制；

SPOT : Single Point Of Truth 真理的唯一、清晰、权威表示

DRY : Don't Repeat Yourself 不要在两个地方有同一数据的不同表达 No Junk , No Confusion

平衡，拆分，合并，转化

语言会影响思维模式

需要，而且是不同范式的语言

异步：

吞吐量提高，

瞬时快速与持续慢速的匹配、

系统关注点分离：任务发送方和处理方分离、

扩展性强：处理可以独立于产生方横向扩展

复杂度

计算编程的本质就是控制复杂度 - Brian Kernighan（贝尔实验室，普林斯顿大学教授，Unix先驱，C语言标准“K&C”中的“K”，《C Programming Language》的作者）

用清晰的接口把若干简单的模块组合成一个复杂软件 如此一来，多数问题只会局限于某个局部，那么就还有希望对局部进行改进而不至牵动全身 - Fred Brooks（人月神话作者，1969图灵奖得主）

怎样叫简单、怎样实现简单，怎样实现可依赖、可依赖的系统依赖什么？

分布式系统健壮性 “定理”： 参见 Distributed_transaction

子系统确定的响应 -可以不反馈（处理中），但反馈的结果必须是确定的。

子系统支持幂等性（可重试）

“防重”、“防漏”。

健壮应对的是系统和IO异常，面向的不是开发人员而是、测试、运维、用户、破坏者。

已经被数理逻辑证明了的计算机科学原理（数据结构、离散数学、数据库、操作系统原理等），企业级软件经过业界实践千锤百炼验证的确定性。

DDD 的分层思想

不 拼（concat / compete）SQL 的架构

子系统的相互依赖少，使你可以在一段时间专注问题的一小部分，精心的设计

《代码大全》倡导的 Managing Complexity

《UNIX 编程艺术》倡导的 Keep It Simple，Stupid

简单

分层

健壮

程序员的修养

计算机科学 ！= 程序设计语言 Programmer ！= Coder

高效程序员的45个习惯

程序员的职业素养：The Clean Coder

代码注意的细节