关注于真正的收益而不是技术本身
- 是否可以降低技术门槛加快整个团队的开发流程。
- 是否可以让整个系统可以运行的更稳定。
- 是否可以通过简化和自动化降低成本。
以应用服务和 API 为视角，而不是以资源和技术为视角
整个组织和架构的优化，需要有一种自顶向下的，整体规划，统一设计的方式，才能做到整体的提升
选择最主流和成熟的技术
- 尽可能的使用更为成熟更为工业化的技术栈，而不是自己熟悉的技术栈。
- 选择全球流行的技术，而不是中国流行的技术。
- 尽可能的使用红利大的主流技术，而不要自己发明轮子，更不要魔改。
- 绝大多数情况下，如无非常特殊要求，选 Java 基本是不会错的。
#完备性会比性能更重要
- 使用最科学严谨的技术模型为主，并以不严谨的模型作为补充。
- 性能上的东西，总是有很多解的。
制定并遵循服从标准、规范和最佳实践
- 服务间调用的协议标准和规范。这其中包括 Restful API路径, HTTP 方法、状态码、标准头、自定义头等，返回数据 JSON Scheme……等。
- 一些命名的标准和规范。这其中包括如：用户 ID，服务名、标签名、状态名、错误码、消息、数据库……等等
- 日志和监控的规范。这其中包括：日志格式，监控数据，采样要求，报警……等等
- 配置上的规范。这其中包括：操作系统配置、中间件配置，软件包……等等
- 中间件使用的规范。数据库，缓存、消息队列……等等
- 软件和开发库版本统一。整个组织架构内，软件或开发库的版本最好每年都升一次级，然后在各团队内统一。
Restful API 的规范
服务调用链追踪
Google Dapper 这篇论文，目前有很多的实现，最严格的实现是 Zipkin，这也是 Spring Cloud Sleuth 的底层实现。
软件升级
重视架构扩展性和可运维性
- 通过服务编排架构来降低服务间的耦合。比如：通过一个业务流程的专用服务，或是像 Workflow，Event Driven Architecture ， Broker，Gateway，Service Discovery 等这类的的中间件来降低服务间的依赖关系。
- 通过服务发现或服务网关来降低服务依赖所带来的运维复杂度。服务发现可以很好的降低相关依赖服务的运维复杂度，让你可以很轻松的上线或下线服务，或是进行服务伸缩。
- 一定要使用各种软件设计的原则。比如：像SOLID这样的原则（参看《一些软件设计的原则》），IoC/DIP，SOA 或 Spring Cloud 等架构的最佳实践（参看《SteveY对Amazon和Google平台的吐槽》中的 Service Interface 的那几条军规），分布式系统架构的相关实践（参看：《分布式系统的事务处理》，或微软的 《Cloud Design Patterns》）
对控制逻辑进行全面收口
- 流量收口。包括南北向和东西向的流量的调度，主要通过流量网关，开发框架 SDK或 Service Mesh 这样的技术。
- 服务治理收口。包括：服务发现、健康检查，配置管理、事务、事件、重试、熔断、限流……主要通过开发框架 SDK。如：Spring Cloud，或服务网格 Service Mesh 等技术。
- 监控数据收口。包括：日志、指标、调用链……主要通过一些标准主流的探针，再加上后台的数据清洗和数据存储来完成，最好是使用无侵入式的技术。监控的数据必须统一在一个地方进行关联，这样才会产生信息。
- 资源调度有应用部署的收口。包括：计算、网络和存储的收口，主要是通过容器化的方案，如k8s来完成。
- 中间件的收口。包括：数据库，消息，缓存，服务发现，网关……等等。这类的收口方式一般要在企业内部统一建立一个共享的云化的中间件资源池。
对此，这里的原则是：
- 你要选择容易进行业务逻辑和控制逻辑分离的技术。这里，Java 的 JVM+字节码注入+AOP 式的Spring 开发框架，会带给你太多的优势。
- 你要选择可以享受“前人种树，后人乘凉”的有技术红利的技术。如：有庞大社区而且相互兼容的技术，如：Java, Docker, Ansible，HTTP，Telegraf/Collectd……
- 中间件你要使用可以 支持HA集群和多租户的技术。这里基本上所有的主流中间件都会支持 HA 集群方式的。
不要迁就老旧系统的技术债务
-
使用老旧的技术。比如，使用 HTTP1.0， Java 1.6，Websphere，ESB，基于 socket的通讯协议，过时的模型……等等
-
不合理的设计。比如，在 gateway 中写大量的业务逻辑，单体架构，数据和业务逻辑深度耦合，错误的系统架构（把缓存当数据库，用消息队列同步数据）……等等
-
缺少配套设施。比如，没有自动化测试，没有好的软件文档，没有质量好的代码，没有标准和规范……等等
-
与其花大力气迁就技术债务，不如直接还技术债。是所谓的长痛不如短痛。
-
建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不要让技术债侵入“新城区” 。
