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

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组件、通用服务、业务服务都有可能出现问题,而且我们私有化部署现场众多,运维人员水平参差不齐,导致运维定位问题效率很低,只能靠增加培训,增加自动化监控&巡检等手段慢慢缓解。