最近，参加了很多内部或外部的技术架构的分享，个人学习过程中也时常偶然偶尔在各种博客文章、公众号文章等其他情况下常常看到有关架构设计的资源资料。
其中的设计思想有很多是可以参考和借鉴的，本文针对个人粗浅的理解，进行个人总结和记录，仅供参考。比较关键的设计思想如Trade Off(权衡)、架构的健壮性考虑因素包含且不限于三高（高性能、高可靠、高并发）等、DDD领域设计（如领域事件、增加防腐层）、分层设计思想（MVC架构、适配层、类似DDD防腐层的Transformation Data数据转换层、业务层与存储层）等的层级间解耦思想等。
”权衡“，这个思想是最近我比较觉得有意思且个人很赞同的一种设计理念。有关架构设计流传一句”名言“：没有最完美的架构，只有最合适且适合的架构。
这个权衡包含很多因素，如当前的业务场景、可行性技术方案的落地成本（机器集群预算成本、开发人员人力成本、后期运维维护成本等等等），简而言之，有些决策是需要Boss层面考虑的，是投入与产出的trade off。以最低的成本做到当前最优的架构方案才是“王道”。
这个段落除了简单的搭建服务集群，增加副本等常规设计思路。将从一些特别的”点“做到高可靠的能力。
如在服务设计实现业务场景中考虑针对关键“业务节点”、“里程碑事件”做好数据的可靠性校验。
设计思想如：业务逻辑触发前、触发过程、结束后等关键阶段做好相应处理。”前期存储快照或通知、中期check、后期对账“。做好快照数据存储、事件通知或"double check"数据快照对账等等。考虑ODPS Flink/Spark 近实时/离线 流数据分析，比对。中央数据中心的统一数据准实时性、MQ事件通知&重试、后台Job Task check&alarm等、分布式事务的解决方案如TCC/2PC/3PC/消息记录表最终一致性柔性事务等。
高并发过程中常常有”加锁“的设计思想，用于保障并发过程的某些”顺序“特性场景。而分布式加锁场景常见的如利用其他中间件实现：如Redis的lua脚本/setNx/watch Dog/Redission等等，zookeeper的顺序临时节点加watch机制，mysql等数据库的悲观锁 如select ... from table where status=' ' for update等。
除了类似“悲观锁”的实现（对并发性能影响较大，又类似上面说的trade off权衡的概念），还可以利用”乐观锁“ 如CAS（compare and swap）思路。防止ABA问题 可以再增加一列快照版本号保证。 mysql 库实现乐观锁举例如update .... where status=' ' and snapshot_version=' '；
关注点评估：
1、调研相关技术的生态环境。如技术社区活跃程度、未来的持续发展前景等
2、学习、开发成本问题。新技术的”上手“效能、后期的二次开发能力、团队的接受性（如是否跨语言，跨技术栈）
3、横向与纵向对比技术框架或架构方向的优劣势。如三高（AP or CP）的实现与支持、长远考虑后续可能的“迁移”成本、是否支持跨机房、多数据中心存储、多集群多租户隔离等、数据迁移的平滑程度
4、评估性能。CPU、Mem、网络IO、磁盘占用等对机器性能的最低支持。高并发Multi Request、吞吐量、响应耗时RT、容错能力等指标
etc...