【技术沙龙总结】福州朴朴01期 - 演进史

前言

一直都很期待福州有一些技术氛围，前几天看到便报了名，早上醒来看到下着大雨，竟然想了一会要不要去！地点福州上下杭鹿森书店，雨后的上下杭搭着小桥流水，有点乌镇的影子。

下面以学习的姿态凭借记忆回顾一下技术沙龙的内容。

整体演进史

对于一家2016年成立的公司，没有那么多的历史技术包袱算是特别幸运了，因为历史债务的堆积，会直接影响到业务的开发效率。
单体：对于产品需要快速抢占市场，方法欠妥，但是当下唯一正确；人力简单。
服务化：随着业务的复杂性扩大，业务拆分不可少；人力团队功能性划分。
微服务：业务与应用间复杂性继续扩大，微服务来了，同时技术复杂性越高；开始组织结构业务性调整。
网格：当下理解是降低微服务的复杂性，让微服务注重业务开发，使系统复杂性可控。


那么为何不一开始就使用网格呢？就像奴隶社会无法跳过封建社会直接进入社会主义社会。

单维度演进史

1、后端
谈到了AKF拆解，书籍《架构即未来》 -> 对于服务的扩展可以采用AKF扩展立方体，XYZ三个维度。
对于单体则是X维度扩展，服务/数据的复制（加机器）。微服务则是X+Y维度扩展，职责/功能拆分（异步化，多数据源）。网格则是X+Y+Z维度扩展，服务/数据的分区（分库分表，集群）


2、前端
灵活性升级，单体的前后端分离摆脱后端束缚。使用React，less+typescript，webpack摆脱重复逻辑获得灵活性进入前端微服务。后续再升级摆脱其他前端依赖进入网格。


3、运维
单体：人工部署，nginx，外部监控
服务化：自动化部署，kong，grafana（业务非通用，产生自研需求）
微服务：k8s，自动化测试与部署，全方位监控，Prometheus，自定义监控（系统复杂化，存在各种自定义监控）
网格：自动化压测，app前端发布集成，流量回放，预警与流量监控，灰度环境（事前保障）


期间单对这一块进行了技术深入扩展：
在分布式系统中，排查问题的复杂度就特别高，因此谈到了全链路追踪技术，这一块特别好用，可以追踪到一个请求从开始到结束所经过的链路，对于微服务来说，可以快速近乎精准定位哪个地方出现了问题（目前左耳用到的是pinpoint）

当然还有以下好用的工具：
日志：多台服务日志排查就很麻烦了，因此需要集中的elk日志进行统一查询
监控：可以自定义条件触发告警等，经常可以通过监控来发现一些隐藏问题与性能瓶颈
部署：这一块感触颇深，从开始的手动sftp部署，到shell脚本半自动部署，再到k8s自动部署。


4、组织结构
理论上纵向划分为：后端，前端，客户端，测试四个组。但是存在问题是四个组互相的不了解，这时纵向可引入产品组，当业务复杂性继续扩张时，可以横向在引入商品组，订单组。

组织架构对应有个康威定律，意思是组织架构会影响到产品，因此组织架构要按技术架构来组建。

总结

在整个过程中，扮演者学习者的角色，并蹭点吃的哈哈哈，干货满满，所以有比较强的欲望把它记录下来，也期待下一次的沙龙。