从4月起，通勤由自己开车改为班车，每天一下子多出了近1个半小时来阅读。用文石结合微信读书，体验很好。偶然发现《凤凰架构》，评价很高，内容很贴切自己的工作实践。拿来一读，酣畅淋漓，这是一部讲架构的书，首先讲到了架构演进的历史：

1、架构演进的历史:

架构演进的历史经历了单体、微服务、后微服务、无服务的过程，但架构本省并没有高低贵贱之分、每种架构都有适用的场景。一个系统最终的架构选型有技术层面，生产关系层面，政治层面等种种因素制约。

1.1 正确的架构路线

比如我们的行业，AI安防平台系统，业务模块较多，功能迭代快，私有化软硬件环境复杂，就很适合微服务来隔离业务模块，简化部署成本。从技术角度看无疑是合适的，从生产关系的角度呢？ 我们10+人的后台团队，有1-2人具备运维K8S、微服务架构的成功经验，整个团队步调一致，业务拆分明确，领导支持，从生产关系上也适合微服务架构的，所以我们最终能完成一套符合我们业务场景的微服务系统。

1.2 右倾的架构路线

假如另一家AI公司，虽然从技术角度也是适合微服务架构的，但业务模块耦合严重，人员盘根错节，无人敢于承担重构导致的项目风险，则也不会采用微服务的架构。这就视为右倾保守主义。

1.3 左倾的架构路线

另一个例子，假如有一家小程序公司，业务很简单，只有一些简单的数据查询，开发人员也只有2-3个。假如其技术人员，看到了微服务的优势，但全然不顾及自身业务情况和技术积累，贸然切换到K8S, 框架本身比业务还要复杂很多倍，恐怕肯定会出乱子、把项目搞黄的。这种是左倾冒险主义。

然后讲了微服务依赖的底层技术

2. 微服务依赖的底层技术

  • 远程调用方式
  • 事务
  • 缓存
  • 负载均衡
  • 安全通信
  • 服务发现
  • 日志
  • 链路追踪
  • 监控

然后讲docker和k8s部分，这部分是我们平时用的很多的，就不总结了。

接着讲到了很火的服务网格，按个人理解，服务网格对我们不是不可或缺的技术手段，它只是用一个更优雅的方式解决了部分服务治理（重试、熔断、鉴权、上报等）问题，而这些问题我们已有其它落地方案，并且没有发现我们的方案有明显不足之处，所以我们暂时还未规划引入服务网格。

3. 必然的意外故障

全书读完，非常同意并警醒于作者的一个观点：

一个大的服务中，程序可能崩溃、节点可能宕机、网络可能中断，这些"意外情况"其实全部都在"意料之中"

对于程序必然的意外，这一点我们应对不足，系统还存在着一些短板服务，但我们依然存在着侥幸和依赖运维解决的心态，这一点需要在下半年重点克服。

4. 微服务的两大优势：

谈一下自己对微服务的理解，微服务架构在我看来优势有

  • 分而治之，生产效率提升。 《国富论》中提到分工极大的提高了生产效率，在后台架构领域，微服务架构就是分工，使每个开发人员可以只关注自己负责的模块，而不用关注复杂的系统整体，提高生产效率。同时隔离了风险，不会因为某些服务导致系统整体不可用，也降低了人员流动导致的代码学习成本。

  • 工业级的治理软件。《荀子》中提到 “君子生非异也，善假于物也”。微服务领域的Docker、K8S、Grpc、Prometheus、ELK等基础软件（或技术）生态已建立，并在成千上万的服务器上稳定运行，我们完全拿来为我所用，更高效的建设自己的业务系统。

5. 微服务的一大劣势：

  • 复杂性高。复杂性太高，运维人才跟不上是我们最近2年运维微服务系统面临的最大矛盾。微服务架构，组件众多，服务众多，从机器硬件、系统内核、系统基础软件、Docker、K8s组件、通用服务、业务服务都有可能出现问题，而且我们私有化部署现场众多，运维人员水平参差不齐，导致运维定位问题效率很低，只能靠增加培训，增加自动化监控&巡检等手段慢慢缓解。