抓住关键问题

做架构，一定要先了解清楚具体的场景和需求，抓住问题，理解问题的本质。

高级别的架构师相对低级别的架构师，高级别架构师善于发现问题，能抓住关键问题。

问题往往比解决问题的技术更重要，因为发现关键问题本身就不容易，而抓住了关键问题，解决问题的方案往往就自然明了了。

另外一方面，我们做架构，不能只关注技术。技术本身无高低之间，简单且能解决问题的技术，就是好的技术。所以，我们做架构，不是想着使用“高端”的技术来体现自己的实力和价值，这样很有可能会把架构设计得复杂，而复杂本身就是风险。我们更应该关注问题，抓住问题的本质，用最简单且能解决问题的技术去解决问题。

架构目标

架构的目标是高可用和高性能。

架构模式

像设计模式一样，架构也有架构模式，将一些典型的架构方法总结成解决某类问题的架构模式。

架构模式有：

分层

在横向方面切分系统

分割

在纵向方面切分系统

分布式

分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即不同的模块部署在不同的服务器上，通过远程调用协同工作

集群

对于并发性大的模块，需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务

异步

将一个业务操作分成多个阶段，每个阶段通过共享数据，而不是直接调用的方法进行协作

冗余

服务器冗余，数据冗余，确保服务高可用

• 每个服务至少部署两份，就算服务使用率不高，访问量低，以确保服务高可用

架构技术

如上图，架构可以大体分为：

• 前端架构

• 网关架构

• 后端架构

• 监控架构

• 安全架构

• 存储架构

• 基础设施架构

前端架构

当前前端架构，类似后端微服务架构，也发展出了微前端架构，可以使用不同的前端技术、由不同的团队共同开发同一个前端系统。

基础设施架构

传统的服务，所有的功能和非功能需求都在服务中实现，使用服务非常臃肿。而云原云理念，是尽可能地把非功能需求下沉到基础设施层实现，如服务发现、服务流量管理、故障注入、服务熔断等。kubernates 和服务网络（如 istio）可以很方便地实现大部分非功能需要的下沉，从而保持服务本身的轻薄。越轻薄的应用，越不容易出错。

中台架构

另外，服务轻薄，还是通过技术中台实现。我们将本属于服务可复用的功能点独立出来，形成平台级的功能服务，由多个业务都可以使用，加强服务的复用，以及共同服务的统一管理。而服务不再包含这些功能，而是通过使用中台而独得这些能力。