架构思维提升，掌握架构本质

开篇先回到2018年，当时在和一个大型客户做中台+微服务的交流中提到“微服务是一种架构模式，微服务和云，中台都不是强耦合的”。客户一位负责人还确认性问了句，“也就是说微服务可以不用上云”，当时我给了肯定的回答。时至今日，通过不断的学习和实践，对很多东西有了更更深的认识。另外这两年云原生开始火起来，那么是不是应用跑在了云上，就是云原生呢？随着公有云越来越成熟，很多创业公司，一开始就选择了公有云平台。在公有云上买资源，部署应用。这是云原生吗？我认为其实不是。先来说说云计算，其本质就是按需分配资源和弹性计算。云原生是一种设计模式，而云原生应用是专门为云平台部署和运行而设计的应用，可以充分利用云平台的弹性能力，实现柔性。因此仅仅把应用部署在云上，把云当作物理机的高效替代使用，实际上并不是云原生的应用模式。

架构的本质是 降本增效
在百万架构师课程中讲了4+3的架构思维模型

1. 业务需求 至简抽象 的 分析思维模型 （需求背后的真实问题）

2. 哲学本质的架构设计思维模型
   1)CAP架构设计思维模型 （CAP的原理应用在不同的领域）
   2)BASE 架构设计思维模型

3. 根据场景Balance的架构设计思维模型

4. 适合的架构设计思维模型 ---- 适度超前的架构设计思维模型

归纳为：分析-设计-取舍-合适（关键是适度超前）

软件架构从 单体---》SOA,分层--》微服务、服务网格--》中台架构--》--》云原生 本质上讲 就是拆分 实现逻辑解耦到物理解耦 。那么具体到需求和场景（除了业务，还有人力资源，时间，成本等），在架构的设计上，都可以参考上面提到的思维模型。

单体架构 （ 性能指标RT要求苛刻场景、O2O）

金融的量化交易、高频交易，可能RT相差0.01ms级别也会导致重大的事故。

单体架构拆分时机的判断：1.多个业务同时请求同一个服务 2. 业务请求量增加 3. 开发效率低，迭代变慢。

垂直拆分即SOA架构，单体垂直拆分1个进程为多个物理进程。在拆分颗粒度上按照业务拆分，比如用户服务、商品服务等。也可以根据业务的特点进行API粒度的拆分。以最为普遍的用户服务为例，其里面包含 用户注册，用户登录，用户信息查询。当用户数量达到一定量级用户注册和用户登录相互影响时（也就是读请求和写请求相互影响），我们会进一步根据注册API和登录API划分服务。这个原则也适用于后面的微服务的拆分。

处理服务的拆分，可以看到数据库也按照业务进行了拆分，当单表数据量到亿级别时，还需要进一步进行分表的设计。但是对于分库分表的落地，除了我们在架构设计上感知外比如对MySQL数据库，也可以采用MongoDB,TiDB等NoSQL，NewSQL技术让他们完全替我们完成分库分表的实现。

上面拆分后的用户和商品还是单体，这里就可以根据需要进一步做水平拆分。

结合企业架构中的架构域划分，微服务架构 更适合作为一种业务架构，而不是软件架构。微服务的服务拆分，核心是解决业务颗粒度的问题。只是微服务的颗粒度更小，其组合变化的可能更多，但是治理的成本也更高。服务拆分按照上面的垂直拆分和水平拆分后，基本上也就是我们在为微服务架构中推荐的服务拆分方法了。当然对于业务拆分，你也可以采用DDD。

另外微服务和DevOps加速迭代，提高研发效率的最佳搭配。

服务网格ServiceMesh 通过拆的方式，把服务治理本身相关的部分拆出来，作为独立的服务进程，但是这个进程和原来的服务进程要求部署在同一台机器上(物理机／虚拟机／POD(容器))。通过统一的服务治理拆分，而且可以实现微服务定义中提到的多种语言模型的支持。

中台架构其核心是一种组织架构，在软件架构上可以根据实际情况，选择单体／SOA,分层／微服务 任意一种。也就是说 中台其实和 微服务没有必然关系，一定一定不要搞错了。

上述架构思维模型应对的我认为还是对外界客观世界的反映。实际上在很多系统中特别是大型复杂系统中，还有一个就是关于架构意图的思考。我理解架构意图更多是架构的设计者根据企业一些关键人的想法，在整个架构中注入的一些主观意图，以实现在一些业务划分上的战略构想。