人到中年，时间感觉越来越快，工作、家庭、生活很多事情都需要顾及到，时间也被碎片化，完整的看本书、系统的写篇文章也变得心有余力不足。新年第一天，写篇文章从技术角度对自己的2021年做个回顾和总结，同时也是将一些重要事情做个记录。
过去的一年工作环境和内容虽然都发生了变化，但主要还是围绕在数据领域、云原生技术研究与开发，对之前沉淀积累的一些想法在公司技术平台上进行落地与实践，做了一些从0到1的事情，获得了一些新的成长，遇到了一些新的难题，也有了一些新的思考。
一、技术架构演进的变与不变
过去几年技术的发展可谓乱花渐欲迷人眼，随着以微服务、容器、K8s、为代表的新技术、新架构的火热，之前还有不少人犹豫是否拥抱云计算，现在就劈头盖脸告你云原生时代已然来临，这也难怪很多程序员在干几年后就会感觉学不动了。
究其原因为什么会技术圈会这么“卷”？其实梳理下过去20年软件架构的演进，识别出其中的变与不变，就会有一个更加透彻的认识。
软件架构风格从大型单体（Monolithic）→ 到面向服务（SOA）→ 微服务（Microservices）→ 到服务网格（Service Mesh）→ Mecha架构→ 无服务器架构（Serverless）...
-
单体 早些年软件系统都部署运行在以IBM、HP为代表的大型机上，大型机的优点性能高，稳定性好，这个阶段主要是一些国家大型机构和银行等组织使用。大型机有个问题就是很贵，于是大多数中小企业就逐渐迁移到了小型机上，但软件并未拆分，仍然是大型单体。
单体架构 -
SOA 随着社会发展，企业经营业务越来越复杂，出现了很多竖井式的系统，系统间的服务发现与通信成为了一个网状结构，为了解决这个问题SOA架构应运而生，通过ESB、各接口服务化来实现系统间标准的集成。
SOA架构 -
微服务 随着业务越来越复杂，系统越来越多而且庞大，一个小的功能升级需要整个系统重新发布，可谓牵一发动全身，同时ESB的这个集中单点也带来了性能和扩展问题。于是就出现了微服务架构，提倡将系统按照业务边界进行拆分，变成独立的小系统、由独立的小团队来负责。这种架构将不同业务类型、变更频率甚至开发语言的系统拆分开来，带来了更好的灵活性。
微服务架构 -
Service Mesh 微服务架构依赖服务发现、调用、安全、熔断等机制，前几年主要还是SDK方式提供，主要代表就是Spring Cloud、Dubbo等。但这种方式下，这些基础技术能力是与业务逻辑部署运行在一起的，这给应用开发者带来了很多开发和运维的复杂性和负担。于是Service Mesh又火了起来，将服务调用、安全、通信路由等功能从业务应用中剥离出来，由一个独立运行的Proxy来提供，应用之间通信两边都通过这个Proxy来进行转发（ Sidercar边车模式），这个Proxy也就是Service Mesh的数据面（如开源项目Envoy），同时还有独立于应用部署的控制系统，来负责给这些Proxy分发配置与策略，也就是控制面，数据面与控制面一起构成了Service Mesh（如开源项目istio）。
Service mesh架构 -
Mecha 既然有Service Mesh提供网络层的通用能力，那Event Mesh、Database Mesh也就有了产生的理由，这种Mesh化的架构也演变成了Mecha架构，提供分布式应用所需的生命周期、网络、绑定、状态四个领域的基础能力，目前这种架构还在快速发展中，Dapr是最接近的。
Mecha架构
6.Serverless 前面的各种架构业务逻辑还是打包在一个完整的应用和运行时中，这对于复杂业务系统是适合的，但现实中还有很多集成、定时、事件触发型的逻辑需要实现，也就是常说的胶水代码，这种需求的特点是轻量级、自动弹性扩容、快速实现，这也正是Serverless最适合的场景。通过将业务进一步拆分为函数（FaaS），实现更细粒度的扩缩容，由平台提供网关、事件触发、函数编排、状态存储等能力，进一步简化开发者的心智负担，实现业务的快速开发。Serverless架构将应用开发复杂度降低到了极致，也被Berkeley等机构认为是云原生发展的下一代计算模式。
由上可以看出，新架构的出现，都是因为要解决的问题变得越来越复杂，这种复杂性一方面是由业务场景增多、业务响应速度变快带来的，也就是我们常说的功能性需求（本质上也是市场快速变化导致的）；另一方面是为了提高SLA带来的，这其中主要是非功能需求，度量指标有常见RPO、RTO、TPS、容灾等（包含的技术方案有高可用、高可靠，两地三中心、熔断、限流等）。这也就是架构演进的变。
人的大脑其实并不擅长这种处理复杂性，但可以通过分而治之、拆分、抽象、封装等方法，将一个复杂变成多个简单，由“大”到“小”，这也是这种架构演变的一个共同特点。
还有一个共同特点就是，将非业务功能与业务功能中进行剥离，从而降低业务开发者的心智，他们专心于解决业务功能复杂性，而非业务功能复杂性则由技术平台开发者来解决。从早期的重量级中间件->SDK->Mesh->Serverless，都是通过这种分离来提高研发效能，快速响应创新需求。这些共同点也就是架构演进的不变。
世界的本质就是不断发展变化，这种变化总是会产生新的痛点，而这种痛点又反过来驱动着技术架构的不断演进。
二、数据架构演进下的痛点
同样，数据库系统作为基础技术软件也不同维度进行着演变。
从SQL到NoSQL、NewSQL，从集中式到分布式，从关系型到文档型、KV型，从行存储到列存储，从物理机到虚拟机、容器部署，从云下到云上，从Serverful到Serverless化...
如果我们站在用户角度去看，会发现数据库的这种演变，伴随着其它技术架构的变化，数据库使用的复杂性已经越发突显，与之带来的就是各种痛点。
1. 数据库类型越来越多
不同场景的对数据存储的需求各有侧重，有的要求低延迟快速响应、有的更看重事务完备性、有的需要存储海量数据、支持水平扩展、有的要求更高的SLA，有的则需要可以更高效的支持复杂关联查询，这些不同的需求催生了各种各样的数据存储技术。
例如解决低延迟高响应OLTP场景的关系型数据库，灵活数据模型、高扩展的文档数据库常用作缓存的内存KV数据库、主打高可用、水平扩展的NewSQL分布式数据库，更底层的分布式文件系统等。
选择一种数据库其实并不是选择一个技术，而是三个：数据访问语言（SQL、REST、专有API）、数据模型、存储引擎。
关系型、文档型、面向列、面向行、JSON，KV等在合适的场景中都是有意义的，这也使得应用程序的不同部分通常需要不同的选择。这导致一个艰难的决定：使用全新的数据库来支持新的数据模型，或者尝试将数据插入现有数据库。
2. 微服务下数据系统越来越多
微服务架构下，数据库库被拆分为多个，每个微服务都创建一个数据库，所带来的自由以及不同数据存储的技术选择也成为了一个挑战：
- 微服务只能访问自己的数据集；
- 数据存储的扩散proliferation、多样化的持久层 polyglot；
- 运维大量的数据存储的工具和实践还远没有准备好。
仅仅能可靠的进行存储数据还不够，数据只有转化为真正的业务价值才是有用的，开发运维工程师、AI/ML专家、数据科学家、业务分析师，他们都希望深入挖掘数据，但是面向应用的微服务以及它们的数据访问模式并不是为这些多元的数据需求而设计的。
3. 云原生下对数据库访问需求的多样性
- 连接性能 传统应用开发时，我们往往会在应用侧维护一数据库连接缓冲池，这是因为数据库的连接并不是一个轻量级操作，连接池技术通过连接复用可以提升连接性能。但在Serverless架构下，函数的生命周期是短暂的，在短时间内可能会大量创建，这种模型也给传统数据库连接模型（TCP长连接）带来很大挑战，基于Http的短连接则更加适合。
- 数据模型与访问差异 应用对数据模型、访问方式也希望尽可能统一，比如交易数据存放在MySQL中，IoT数据则存放在MongoDB中，但前者需要建立schema，通过SQL方式操作，后者则无需建立schema，通过MongoDB专有的API来访问，这种差异性也给开发者带来了很多负担。
4. 对数据库资源响应速度、运维自动化程度要求
市场对于业务创新响应速度越来越快，一个系统恨不得今天提需求，明天开发，后天就上线，这对于数据库资源的申请、创建、运维等提出了更高的要求。流程要更加自动化、监控更加准确，对故障可以自动定位，同时给出建议的解决方案，降低数据库资源管理工作量与复杂性。
5. 对数据库分布式、高可用能力的要求
数字化时代，移动设备、IoT都带来了数据爆炸式的增长，传统集中式的数据库在存储和吞吐性能等方面都无法满足这类场景，数据分片、读写分离、分布式事务、异地多活等能力都需要数据系统进行提供。
6. 对数据库保护能力的要求
网络安全问题越来越重要，数据库作为企业数据资产的保险箱，对数据库的保护能力的要求也越来越高，SQL熔断、限流、安全连接，数据加密、SQL审计、SQL防火墙、全链路压测等功能诉求也越来越高。
7. 对自动扩缩容、按实际使用计费能力的要求
传统的数据库资源都是预置的，应用方需要根据业务量增长估算一个高于水位的资源配置。但随着越来越多应用的上云，以及Serverless架构的普及，用户对于数据库也希望是用的时候再分配资源，根据实际使用情况付费。这也就要求数据库要能根据负载自动进行扩缩容，也就是ServerlessDB，比如Aws的 Aurora serverless，现在很多数据库也都开始探索Serverless化。
如何为用户屏蔽这些复杂性，解决这些痛点呢？
如第一章所述，问题解决往往不止一种方式，不同的实现技术之间也在逐渐融合。
比如微服务之前有Spring Cloud、现在围绕k8s的实现方案也渐趋完备、Serverless更是提供了一种极致的方式；虚拟化技术早有虚拟机、后来出现了容器，再到现在的轻量级虚拟机以及安全容器技术；Service Mesh最初主要是proxy模式、后来又有了proxyless，同时还有下沉到内核层基于eBPF技术的方案。
解决上述数据这些问题目前也有两种方式：
- 横向 在数据访问层、数据库中间件、网关，增加提供更多覆盖各类数据库的能力。
- 纵向 在数据库测，通过新的数据库，包含传统数据库欠缺的功能。
- 前者的思路是集成，最大程度复用底层数据库已有能力，增加欠缺的功能；一些知名的开源项目Apache Drill、Teiid、ShardingSphere，这种更多扮演的是SQL引擎、数据网关的角色。
- 后者的思路是重建，将数据分片、分布式事务、高可用等能力内置在原生数据库中；这类项目的定位就是分布式数据库，比如TiDB、CockcoachDB、OceanBase等。
- 当然还有一种是融合方案，底层存储基于关系数据库进行改造，对XA事务、主从同步等方面进行了一些增强和优化，Proxy层与中间件方案类似，完成SQL路由、分布式事务协调功能，采用这种方案的有TDSQL、GoldenDB等。
三、想做什么，做了什么
架构的演进、系统的拆分、数据存储技术的多元化、数据的分散化带来了越来越高的复杂性，如何封装、降低这些复杂性带给上层应用的侵蚀，给应用开发者提供一个更加简单易用的数据库服务呢？这也是过去一年中一直思考的问题，那么对于用户来说，理想的数据库服务是什么样呢，下面是我们对此的一些想法也是愿景：
理想的数据库服务
- 无需关注这个schema中的表存储在什么数据库；
- 无需在关注数据库连接是否够；
- 无需预估容量需要多少，业务负载高时扩容，低时释放降本；
- 无需考虑采用什么高可用、高可靠方案；
- 无需考虑异构数据库之间的数据复制以及操作差异；
- 应用只需要管理自己的schema，通过SQL、KV、GraphQL等标准方式进行访问；
- 如果SQL运行有问题，会自动给出问题原因，以及优化建议；
- …
这些愿景正是我们希望实现的，也是项目的建设目标。综合考虑到技术积累以及公司内技术架构的一些原则，我们最后采用就是方式一，通过Proxy、SDK、IDE、管控台实现多种数据库（MySQL、MongoDB、Oracle、NewSQL）的统一接入，同时适配多种场景（传统常驻应用、Serverless FaaS），支持HTTP、MySQL协议方式连接，通过自动扩缩容、SQL级熔断限流、链路跟踪等提升性能，降低运维复杂度、提高响应速度，提供更好用的数据库服务。
完成情况
过去的一年，我们发布了三个内源版本，同时在行内Serverless平台进行了投产试点。目前已实现了多协议以及多种数据库的支持，MongoSQL模块也创新性的提供了SQL操作MongoDB的功能（目前业界还未有类似成熟开源项目）。另外也已完成JS与Java的SDK、管控台与IDE正在进行最后的系统测试，鉴于目前还是一个内源项目，其它技术细节这里就不过多介绍。当然去年完成的还只是项目的几个核心功能，自动扩缩容、安全认证、熔断限流、读写分离、故障定位等功能还需要在新的一年继续完善与补齐。
发现的问题
这种中间件Proxy方式，最大程度复用了关系数据库已有能力，但同时依赖数据库一些接口的开放和能力的增强。比如自动扩缩容，对Proxy的水平扩展能提高应用的数据库连接性能，但如果后端数据库性能到达瓶颈，则无济于事。项目中的Autoscaler更多是个控制器角色，收集各种metric指标，计算SQL运行成本，触发扩缩容。
目前原生MySQL等数据库并不具备这种能力，但新型的一些数据库比如TiDB等则通过存储计算分离、分布式存储、容器等技术实现这些能力，并且提供了对应的API。另外对于数据库本身的资源检测、告警等的集成也面临着很多难题。
四、 开源、内源
开源如今已是很多基础技术的事实标准，互联网自不必说，对于金融业来说，去年10月份人行、工信办、银保监会等部门联合发布的《关于规范金融业开源技术应用于发展的意见》也为各金融公司明确了对开源治理、开源自主掌控、开源生态建设等的要求。
为了更好的进行开源生态建设与实践，过去的一年，我们引入了内源。
内源的定义：Inner source is the use of open source software development best practices and the establishment of an open source-like culture within organizations.
内源是一种文化，其核心在于共享、复用、协作、学习和自动化。在交付中学习、快速迭代，用CI、CD进行质量控制，更频繁的部署，更快速的交付，得到更多的反馈从而不断优化，创建出更好的项目，实现人才与创新能力的培养。
内源的几个目的：
- 重复利用（reuse），比如公共代码的共享与复用
- 协作(Collaboration) ，组织间协作，共同开发代码
- 构建社区（Community）互相学习经验，互相分享，共同进步
- 使开发者更专注于感兴趣的项目，提高效率，实现创新
- 最终目的是以更快的速度构建更好的软件
公司通过内源的方式对开源项目进行了试点，我们的项目作为第一批以开源众创方式进行。开源意味着透明、开放、以及集市式协作，这种项目建设方式与其它内部项目差别还是比较大的，所以团队在开始花了很多精力去编写项目介绍、参与指南、贡献规范、设计logo、建立项目主页站点等等。当然开源远不止是开放源码，年初一段时间还编写了一个开源建设方案并进行了宣贯，参与了中心开源社区运营方案的制定，后面三个季度则投入了很长时间去做项目的开源运营、技术支持、PR审核、贡献激励等事情。
开源不易，虽然它从诞生起就充满理想主义，但全靠爱发电终究难长久，多元、有活力，有合适的商业模式的开源社区才是有生命力的。内源其实也是如此，过去这一年我们很高兴发现了很多技术达人，他们用自己代码让我们项目变得更加优秀，但同时发现开源本身还是要求参与者对此的认可和热爱，能力的提升、名声荣誉的奖励可能比绩效激励长远来看更加有效，如何达到一个平衡，形成正向驱动的闭环也是新的一年需要我们不断探索的。
五、国际代码比赛
翻看去年的Git提交热力图，中间有两个多月空白，这段时间去参加了2021年Call for Code全球代码挑战赛，代码提交到了另外一个环境的Git仓库里。
好的作品首先要有一个好的创意。2021年Call for Code比赛的主题是应对气候危机，我们的作品希望能紧扣大赛主题，响应当下全球碳达峰、碳中和目标关联的同时体现公司特色与优势，另外最重要的是通过技术真正解决实际问题，帮到需要帮助的大众群体。
大家经过多轮头脑风暴、竞品分析、实地考察、集思广益，最后设计了以CSA（Community Supported Agriculture）理念为主题，助力可持续农业生产和绿色消费的解决方案，帮助中小农户进行绿色生产，扩大客源，帮助消费者吃到健康、可信的绿色农产品。两个月的时间，大家完成了原型设计、VR、AR、直播、区块链、联邦学习等技术的攻坚，编码、APP上线、视频制作、作品提交等工作，现在想起来真的像一个初创公司的感觉，在很短的时间亲身见证了一个新产品的从无到有。
很开心最终成绩还是不错的，我们的参赛作品Green Farm获得了全球第二名，关于作品和比赛的其它信息可见Call for Code官网https://developer.ibm.com/callforcode/solutions/2021-solutions/。
Call for Code是全球规模最大的科技向善(Tech for Good)代码挑战比赛，赛事由美国David Clark Cause、联合国人权理事会、IBM、Linux基金会等组织于2018年合作创建。每年的参赛题目都聚焦于联合国可持续发展目标（SDG）下的某个领域问题。赛事迄今连续举办四届，赛事的决赛轮评委由美国前总统Bill Clinton、Linux基金会执行总裁Jim Zemlin等国际名流担当，累计吸引了全球180个国家、50万多名开发人员参与。
六、总结、展望
过去的一年，无论是内源项目还是代码比赛，对我来说都是从0到1的过程，两个创新性质的项目，以开源方式运作，能够在组织已有的技术、运维、项目管理体系下进行尝试，离不开公司以及领导的大力支持，同时也感谢所有团队小伙伴、内源参与者的贡献，正是大家的齐心合力，才能有的去年的这些成果。
展望2022年，希望自己能够更加高效的管理时间，与团队小伙伴们携手共进、不断进步、技术和认知能力都有新突破，也希望继续能有一个鼓励创新的环境，持续打磨产品，完善配套功能与工具，做好运营，让更多的志同道合的小伙伴们加入进来，将1做到N。
最后也祝愿各位亲朋好友在新的一年都能身体安康、工作生活和睦，学到新本领、结交新朋友，未来可期。
《大教堂与集市》有句话，如果你有正确的态度，有趣的事情就自然会找到你。
