https://coolshell.cn/articles/21672.html
1、中间件尽量选择AP系统
2、WatchDog -- 看门狗
3、追问原始需求
4、冗余 -- 数据一致性是很难保证的
进步永远来自于探索，探索是要付出代价的，但是收益更大
原则一：关注于真正的收益而不是技术本身
1、是否可以降低技术门槛加快整个团队的开发流程
系统架构需要能够进行并行开发、并行上线和并行运维，而不会让某个团队成为瓶颈点。
2、是否可以让整个系统可以运行的更稳定。
要让整个系统可以运行的更为的稳定，提升整个系统的 SLA，就需要对有计划和无计划的停机做相应的解决方案。
3、是否可以通过简化和自动化降低成本。
最高优化的成本是人力成本，人的成本除了慢和贵，还有经常不断的 human error。除此之外，是时间成本、资源成本、资金成本。
原则二：以应用服务和 API 为视角，而不是以资源和技术为视角
基础架构和运维工作关注点不同。整个组织和架构的优化，已经不能通过调优单一分工或是单一组件能够有很大提升。一种自顶向下的整体规划、统一设计的方式来大幅提升整体效率；站在服务和对外API的视角来看问题（DevOps），而不是技术和底层的角度。
原则三：选择最主流和成熟的技术
1、尽可能的使用更为成熟更为工业化的技术栈，而不是自己熟悉的技术栈。
2、选择全球流行的技术（普适性），而不是中国流行的技术。
3、尽可能的使用红利大的主流技术，而不要自己发明轮子。
想尽方法跟整个产业、整个技术社区融合和合作，这样才会有最大的收益。
4、绝大多数情况下，如无非常特殊要求，选 Java基本是不会错的。
事务处理、复杂的交易流程 | 社区、Spring框架、中间件、方案
原则四：完备性【扩展性】会比性能更重要
1、使用最科学严谨的技术模型为主，并以不严谨的模型作为补充。
2、性能上的东西，总是有很多解的。
原则五：制定并遵循服从标准、规范和最佳实践
1、服务间调用的协议标准和规范：Restful API路径、HTTP 方法、状态码、标准头、自定义头，返回数据 json scheme……
2、一些命名的标准和规范：用户 ID，服务名、标签名、状态名、错误码、消息、数据库
3、日志和监控的规范：日志格式，监控数据，采样要求，报警
4、配置上的规范
5、中间件使用的规范。数据库，缓存、消息队列
6、软件和开发库版本统一。软件或开发库的版本最好每年都升一次级，然后在各团队内统一。
Restful API 的规范 | 服务调用链追踪 | 软件升级
原则六：重视架构扩展性和可运维性
扩展性：标准规范且不耦合的业务架构 | 可运维性要求的则是可控的能力
通过服务编排架构来降低服务间的耦合 | 通过服务发现或服务网关来降低服务依赖所带来的运维复杂度
一定要使用各种软件设计的原则：SOLID、IoC/DIP、SOA 或 Spring Cloud
KISS（极简、所见即所得）
原则七：对控制逻辑进行全面收口
1、选择容易进行业务逻辑和控制逻辑分离的技术：JVM+字节码注入+AOP
2、中间件尽量选择AP系统
收口：流量、服务治理、监控、资源调度（CICD）、中间件
原则八：不要迁就老旧系统的技术债务
防腐层 + 规范
