01 云原生

云原生是一个不断变化的概念，它的定义也在不断变化，其解释权不被个人或某些组织所有。但大体上，云原生(CloudNative) ，云指的是应用位于云中，而不是传统的数据中心；原生是指应用在设计之初就是以在云上运行为目标的，最大限度的利用云的分布式、高弹性等优势。

Pivotal 公司于 2013 年首次提出云原生（CloudNative）概念，现在 Pivotal 已成为了 Vmware tanzu 的一部分，他们最新的官网对于如何构建云原生应用描述了以下 4 点：

DevOps： DevOps 是软件开发人员和 IT 运营之间的协作，旨在提供解决客户问题的高质量软件，使构建、测试和发布软件可以快速、频繁且更一致地进行。

微服务： 微服务是一种将应用程序开发为小服务集合的架构方法；每个服务都实现业务功能，在自己的进程中运行，并通过 HTTP API 或消息传递进行通信。每个微服务都可以独立于同一应用程序中的其他服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分，可以在不影响客户的情况下频繁更新实时应用程序。

容器化： 与标准虚拟机 (VM) 相比，容器有更高的效率和速度。使用操作系统级虚拟化，单个操作系统实例在一个或多个隔离容器之间动态划分，每个容器具有唯一的可写文件系统和资源配额。创建和销毁容器的低开销以及单个 VM 中的高打包密度使容器成为部署单个微服务的理想计算工具。

安全性： 云原生安全基于以下三个原则提供了一种降低企业风险的变革性方法：更新可用时立即修复易受攻击的软件；经常从已知良好的状态重新修复服务器和应用程序；经常轮换用户凭据。

总而言之，云原生架构的应用程序应该是：采用容器化方案，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率的应用程序。

  • 云原生构建应用简便快捷，部署轻松自如、按需伸缩、架构灵活；
  • 相比 OpenStack 等虚拟化方案，减少了虚拟化的开销、部署成本低、性能更好；
  • 相比纯 Docker 集群，有更好的编排能力，维护性更好，可用性更高，可以减少故障率；
  • 而天生对微服务的支持也使得高内聚、低耦合可以轻松实现，使得运维、扩容、敏捷开发变得更加容易；

云原生的优点不一而足，缺点却难以与其相提并论。

02 微服务

软件设计有两个关键目标：高内聚、低耦合，围绕这 2 个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则，这也即是微服务的原则。

一个项目，开始搭建时总会有预料不到的后续问题，随着用户和业务的增长，性能就会出现瓶颈，或者项目的架构难以满足业务需要，这时候除了常规的代码优化外，就需要拆分服务了。

举个例子，一个项目刚刚创建，谁也不知道它未来要服务多少客户，5 个人的团队就能完成全部的开发任务，每个开发人员都对项目的代码心中有数，但随着业务的增长，复杂度的提升，团队从 5 个人变成了 50 个人，代码也从几千行到了几十万行，这时候单一的开发人员就很难对所有的代码都做到“心中有数”了，而当代码数量再度增加，业务也更上一个层级的时候，单纯的某一个子业务的代码就已经复杂到需要一个团队来开发维护了，此时老的架构已经不能支持业务的需求，对代码的维护也成了一个难题。

更好的做法是，在某个合适的时间点把代码按照核心功能拆分成一个个微服务，每个服务只关注自己的实现，每个服务都可以单独开发和部署，每个服务都可以交给一个团队，服务之间通过预先定义好的接口进行通讯。这样，每个团队只需关心自己负责部分的代码和功能，而个别服务出现故障也不会影响其他服务，而且采用这种架构我们可以快速进行迭代开发，提高交付效率。

Authing 就采用了微服务架构，这样可以带来最大的灵活性、可靠性和开发效率。

03 高可用

高可用是一种面向风险设计，使系统具备控制风险，提供更高的可用性的能力。
从概率学上讲，凡是可能出错的，随着次数的增加，出错将是不可避免的，这时我们就需要预先对各种风险作出评估，通过种种手段抑制避免这些风险，保障服务的可用性。

云原生和微服务虽然很好，具有灵活可拓展等一系列的优点，但想要做到高可用，还需要做很多努力，我们从控制风险、问题追踪、故障解决三个方面来讲：

1. 控制风险

控制风险有四大因素：

  • 减少风险数量：从源头上减少风险，比如外面下雨你不出门，那你就没有被雨淋的风险；
  • 降低风险变成故障的概率：比如在任何可能阻塞业务的代码中加入错误冗余处理使其不阻塞其他业务；
  • 减少故障的影响范围：把整体业务拆成一个个微服务，某个服务挂掉了，不会影响其他服务的正常运行；
  • 缩短故障影响时长：事前做好预警工作、平时做好监控工作、有充分的预案和灾备、事后做好复盘，能自动化的操作尽量自动化，需要人工的操作尽量一键化，比如一键切换、一键回滚、一键扩容等等。

Authing 为了避免风险作出了诸多努力：在测试前会使用 Sonar 等工具检查代码质量、每次上线前都会进行多轮的冒烟测试、对于线上还会有定时的自动化测试脚本，一旦某个环节出了问题，就会自动预警以及时修复等等。

2. 问题追踪

平时要做好监控，发现问题才好追踪。对于云原生应用来讲，需要保证各个层面都有监控，日志集中管理，出现问题才好随时复盘，还应利用好各种工具来检测服务和集群的各项指标，出现问题前及时预警。

Authing 采用了 prometheus 、 grafana 等工具实时检测服务的各项指标，前端也做了相关埋点工作，并在各个层次和维度上记录了详细的日志统一管理，从开发、提测到上线，每一个节点都有记录了明细的相关文档可以追踪，这样可以保证及时预警避免事故发生，即便出了事故也可以快速定位修复问题。

3. 故障解决

即便做了这样或那样的努力，有时候还是无法避免故障的发生，这时候就要尽快解决问题。在平时做了充分监控和记录的前提下，查阅日志和监控记录，复线问题，定位代码以找到错误并修复问题的速度就至关重要了。

Authing 采用了微服务架构，当问题出现时我们可以快速定位哪个模块出了问题，根据已有的日志和监控，快速定位、复现问题并解决问题，事后通过复盘避免类似事故的再次发生。

Authing 作为 SaaS 产品一直致力于提高自己的可用性，给客户更好的体验，我们会不断优化自己的架构，不断实践，不断进步。