随着新冠疫情在全球的蔓延，企业内外部非接触的在线协同工作显得越发重要，也正因如此，部署快、性价比高、协同性好的SaaS软件越来越受到市场的追捧，随着用户的不断增加，如何提高产品研发迭代效率、提高系统稳定性，就成了每一家SaaS化产品公司面临的问题。
以千丁云产品为例，其功能价值在于利用AIoT赋能物业行业，助力社区服务实现智慧化转型，让物业员工间的协作线上化、数据化，让物业对业主的服务智能化、信息化。为了让整个系统更加稳定高效，近期千丁互联已将整个技术栈迁移至全新的云计算环境，实现了技术上的跨越式进步。
一、三朵云：容器云、研发云、监控云
云计算这一概念被提出后，一直在业界受到持续的关注、研究及应用。部分专家学者将云计算分为三层：IaaS、PaaS、SaaS，相比较而言，IaaS、SaaS容易理解，而PaaS则相对模糊，在业界分歧较大。简单而言，IaaS提供计算、存储、网络能力支撑整个计算机系统运行，SaaS提供面向多租户的应用系统，而PaaS则是面向应用提供丰富的运行时环境，如不同语言、数据库、中间件等环境。为了减少不必要的分歧，结合DevOps实践，千丁云研发小组定义了容器云、研发云、监控云三个产品，简单来说容器云负责提供程序运行时环境，研发云负责程序编译、部署，而监控云则负责整个系统运行时监控。
1.1 容器云
云计算技术兴起之初，以整合计算、存储、网络等虚拟化技术的OpenStack做为第一代标志产物，被国内外各大公有云厂商所使用，但由于OpenStack设计复杂等问题，各大厂商均以此做为基础进行改进。不久之后，随着以Docker做为代表的容器技术兴起，以及Google将Kubernetes贡献到开源社区，业界逐渐把目光聚焦到基于Kubernetes及Docker构建的容器云上，并将之称之为第二代云计算技术，这两者各有优缺点，并非简单的替代关系，对此千丁云研发小组结合业务特点对这两种技术在千丁互联的应用做了详细的评估。
综合而言，OpenStack更适合公有云厂商使用，提供面向多租户，网络、存储、计算隔离较好的公有云IaaS环境，用户可以基于这种环境部署应用、数据库及各种中间件。而Kubernetes则更适合企业内部，面向应用提供运行时环境，并不适合部署数据库、中间件等系统。结合千丁互联的业务场景，千丁云研发小组选择了Kubernetes做为云计算基础环境，将应用程序部署于其上，而数据库、中间件等对可靠性要求较高、数据需要持久化存储的系统，仍然采用物理机进行部署。与此同时，先后与华为云、京东云、UCloud建立了良好的合作关系，不断深化合作，使得容器云快速上线。至今生产环境已经有100余个系统运行在基于Kubernetes的容器云环境中。
1.2 研发云
通常系统研发与上线、部署通常分属于研发和运维等不同部门，部门间的协同经常会导致上线时间长、失败率高，这也是业界经常出现的问题。为了解决这一问题，提高研发效能，千丁云研发小组参照业界流行的DevOps工作模式，开发了一套全新的研发云系统实现CI/CD无运维。
编译程序
CI/CD方面，千丁云研发小组之前使用Jenkins进行构建，但Jenkins仅仅适合编译，而不适合发布。研发云的编译过程他们仍然使用Jenkins，调用Jenkins API进行编译，之前他们的Jenkins编译脚本采用Shell脚本，为了实现多语言环境的Jenkins编译，在研发云的Jenkins环境上，他们启用了Jenkins 2.0之后出现的Pipeline，使用Groovy开发编译脚本，每个Stage根据不同的编译器及版本，在响应的Docker镜像中运行，避免了在一个Jenkins编译主机上安装不同编译环境所引起的环境冲突问题。同时，他们将编译脚本放到Git上，相同语言的项目对应同一个编译脚本，当需要修改编译过程时，只需要全局修改即可。程序编译通过后，将编译好的程序打包成Docker镜像，推送至Docker Hub中，运行时，直接调用Kubernetes API运行指定的镜像。
生产环境上运行的程序，不同于开发、测试环境，需要考虑的更多，如实现资源配额管理、运行时修改配置、系统回滚、蓝绿发布、灰度发布等等。研发云上，他们通过启动系统时设定资源配额的方式，将配额设定传递给Kubernetes，由Kubernetes来管理运行时程序所能使用的计算资源。在运行时修改配置方面，研发云集成了携程开源被业界广泛使用的Apollo配置中心，通过API方式修改程序配置。在蓝绿发布、灰度发布方面，千丁云研发小组正与华为云合作，将Service Mesh的最流行实现方案Istio引入研发云。
Apollo配置
运行时资源配置
1.3 监控云
程序的稳定运行离不开监控，监控云产品就是为实现这一目标所设立。一般来讲，监控主要从基础设施监控、应用监控、用户端监控几个方面进行。对于基础设施监控，千丁云研发小组使用业界比较流行的Prometheus+AlertManager进行监控。对于应用程序监控，主要涉及Log、Metrics、Trace几方面，为此他们评估了业界几个主流的开源产品PinPoint、SkyWalking、ElasticAPM。
由于PinPoint部署过于复杂，需要HBase环境，首先排除PinPoint。SkyWalking告警规则文档描述不清，似乎不能运行时修改告警规则。ElasticAPM不支持Dubbo，但代码结构清晰，监控数据存储在ElasticSearch中，容易扩展开发，同时Elastic APM可以与kibana结合，利用kibana丰富的可视化功能，方便的展示应用运行时信息。结合实际情况，最终他们选择了ElasticAPM做为APM，整个APM架构如下：
为了实现发送告警通知，他们参考Prometheus的PromQL查询语言实现了一套新的查询表达式，方便系统研发使用来进行告警规则设置。比如：avg(http{appname="qdp-polaris-server"} by url range 5m)> 2000，计算5分钟内qdp-polaris-server系统各个http接口的平均响应时间，如果超过2000ms则产生报警。相当于SQL中的select avg(响应时间) from table where timestamp between now() - 5m and now() group by url。值得注意的是，Skywalking 6.5.0后也实现了运行时动态配置告警规则，关于Skywalking他们则将持续关注。
用户端监控方面，目前他们使用监控宝进行监控，周期性查看来自用户端的性能报告来优化系统。
二、架构升级
2.1 Data PipeLine
随着微服务的流行，越来越多的系统从单一且庞大的系统拆分成若干个服务独立运行，尽管有领域建模的指导，但如何进行服务拆分，仍然是一个充满艺术且有挑战的工作。服务的拆分随之而来的是数据的分散，原本集中存储在一个数据库中的数据被分散在不同数据库中，甚至是不同类型的数据库，比如NoSQL。这就带来了一个问题，如何根据业务规则进行数据汇总。
传统上进行多数据源数据汇总，有基于SQL抽取数据、也有基于阿里开源的Canal进行数据汇总处理。SQL抽取数据的方式有一定的延迟，且对表结构有一定的要求，如必须有主键、必须有变更时间戳等。而Canal处理数据又需要进行程序开发。如何开发一个实时的数据同步平台，将数据从不同数据源中相互同步成为他们的一个迫切的需求。
经过一系列调研，千丁云研发小组将目光集中在Kafka Connect上，结合Kafka完善的生态系统，Kafka Connect的特性确实非常引人注意，可以基于SQL、 CDC两种方式进行不同类型数据源间的数据同步。
在Kafka Connect的使用过程中，他们很快发现Kafka connect存在很多Bug，典型的Bug就是时区问题，数据从源表进入Kafka时会被转换成UTC时间，但写入目标表时，却没有进行转换，导致目标表时间显示错误。在启动自动变更表结构时也同样产生错误，没有将原表的表结构同步到Kafka Sink，导致无法执行表结构变更。在数据类型转换时同样出现错误。为此他们通读了Kafka Connect源代码，并与社区合作修复了其中的一些Bug，并基于Kafka Connect的基础上开发了Web管理界面进行数据同步任务管理。
2.2 Service Mesh
随着微服务的流行，人们很快发现需要引入服务治理。之前公司内部使用Dubbo实现微服务调用，但遗憾的是开源版本Dubbo并没有引入太多服务治理功能。随着Spring Cloud的出现，业界很快接受了熔断、限流等服务治理概念，但这些方法均需要对代码进行侵入性改造，且仅限于Java技术栈。
Service Mesh的出现可谓让混沌的世界出现一缕明亮的阳光，Service Mesh配合Kubernets使用，可以在网络层直接进行熔断、限流等服务治理，程序无需改动，带来了全新的服务治理方法。
在ServiceMesh的选择上，由于最初他们使用的是Dubbo，因此希望实现上能够兼容Dubbo，在一次技术交流峰会上，了解到蚂蚁金服开源了新的微服务框架Sofa，千丁云研发小组便将目光聚焦到Sofa上，但经过后期的种种比对、研究，最终还是决定拥抱Istio，整个微服务技术栈由Dubbo转向Http。值得一提的是，华为是Istio的金牌会员，在Istio的使用上他们也与华为建立了良好的合作关系。目前正在研发云上开发Istio的配置，支持蓝绿、灰度发布、熔断、限流等功能。
2.3 缓存云
缓存方面，之前使用Redis Cluster，但Redis没有细粒度的配额管理，容易造成资源使用不均衡的情况。比如个别应用占用太多的内存空间导致其他应用无更多内存使用。为此，千丁云研发小组采用Kubernetes部署Redis，为每个应用单独创建Redis单例或者集群，按需申请Redis资源来解决这一问题。
2.4 CMDB
对于一个复杂的基础设施环境而言，既涉及众多硬件也涉及众多基础软件及应用程序，如何管理这些系统之间的关系成为一个重要的课题。对此千丁云研发小组采用图建模方式，来管理这些关系，图数据库选型上，采用国内最新开源的Nebula Graph，这部分工作仅仅刚开始，相信不远的将来就会完成系统建设。
三、研发中的美学追求
就工程师的群体而言，理性思维远大于感性思维，但在千丁互联，工程师们仍然有着独特的美学追求，简单、干净是他们一直追求的，他们希望所设计的系统无论在架构上还是交互上，都像古希腊的神庙一样，闪烁着理性的光辉，给用户带来愉悦的、超乎预期的体验，这也是千丁互联追求的工程师文化。
四、展望及讨论
基础设施及系统架构建设任重道远，千丁互联也不断与华为、京东、ucloud、360、斗象这些知名的企业合作，共同建设。随着整个技术生态的发展，相信在不远的将来，将会有更多新的产品、新的应用在千丁互联诞生，赋能整个智慧社区生态。也期待着更多的研发领域的有志之士与千丁互联研发小组共同交流探讨，让我们以更开放的心态，携手同行，共同创造更好的未来。