云原生

云源生(Cloud Native)

现在但凡和软件技术有点裙带关系的机构、组织、人士都在谈论各种“云”。还有不少公司以云××、××云、×云×作为公司的名称。与IT技术沾一点边或者完全不沾边的各路人马都可以随时抛出“云应用”、“云计算”、“云数据”等听起来就很高大上的术语持续忽悠着你。

对于云技术(微服务)而言,2013年是一个分水岭,在这之前有一些零散的分布式应用的意识,但是没有一个系统性的概括。然后在2013年Matt StineCloud Native概念横空出世。Cloud Native是一系列概念的集合,围绕这一系列标准可以构建从技术架构、到运维管理、再到团队协作的整体性框架。他让基于微服务的应用搭建过程成为一个标准流程,主要涵盖以下几点内容。

  1. 微服务(分布式系统)

    • 首先,微服务本身就是一个很具体的概念,简单的说就是:根据性能要求横向拆分为相同功能的负载均衡节点,根据业务要求纵向拆分为不同功能的服务节点。
    • 其次,微服务这个术语下还涵盖了大量概念,也是一个概念的集合,比如:熔断、降级、心跳检查、消息队列、负载均衡、服务注册、服务发现、去中心化、服务通信(RPC、RMI、TCP/IP)、分布式事物(分布式数据库)、分布式存储、分布式同步对象(数据)、缓存穿透、缓存雪崩、业务追踪、统一日志管理、API网关等等。每一个概念都是一种标准,都有一项或多项技术在支撑。通常优秀的微服务框架都会实现以上部分功能,同时支持内部或外部扩展。比如要防止缓存穿透可以自己写一个Bloom Filter(布隆过滤器),或者缓存用Redis(>4.0)并添加过滤器插件,再或者在物理缓存之前再使用Redisson、Hazelcast之类的内存级缓存。
    • 最后,微服务也特指云服务分布式系统的底层技术。比如Dubbo、Spring Cloud、以及后面要提到的一系列Service Mesh框架等,都会把他们称为微服务框架。

    虽然微服务这个术语自身已经有了足够丰富的内容,但是他仅仅是“云”技术的一个环节。

  2. 康威定律

    在使用微服务框架的时候,不知道各位有没有想过这些问题:为什么微服务技术或团队是现在的结构?为什么微服务开发需要和敏捷模型(迭代模型)配合?为什么使用微服务的公司能够容忍团队之间使用不同的语言?

    以上这些问题早在半个世纪之前就给出了答案——康威定律。康威定律是微服务技术团队的基础理论,他主要由四个定律组成:

    1. 组织的沟通方式通过系统的设计结构来约束:沟通成本呈现指数增长(人于人之间的连线),必须把业务/小团队边界压缩在固定人员中(5~15人)。

    2. 无法完美但能高效。Bug永远有,与其追求无Bug的完美系统,不如追求可允许的修复速度,进而通过反复验证强化系统。这是敏捷开发、持续集成发布、自动化监控的本源——即使测试覆盖到100%也没法避免不出现bug,但是能在波及面可控的范围内快速解决问题。

    3. 线性团队同质化,业务团队内聚化。看下面2个图就明白(图片来源于网络,如有侵权请联系立即删除)。

      1)云原生_第1张图片

      2)云原生_第2张图片

      图1)是一个线性团队,前端、后端、数据库分工明确层次清晰,然后开发出来的系统也会呈现出对应的样子,因为团队划分的结构决定了系统的最终形态。

      图2)是一个以业务划分的团队,每一个团队都有一个完整的从前端到后端的“生态”。然后开发出来的系统就会各成一派别。

      第三定律告诉我们小团队内部的沟通往往密集而且更加高效,按照这个方式划分的每个子系统自然会逐渐内聚,而团队之间更加倾向以接口沟通耦合性更低。仔细观察,现在包括BAT在内的互联网公司都是图2的团队结构。

    4. 系统的拆解倾向性。在架构演进的过程中,随着系统规模的增加合理的解决方法都是将复杂的问题拆分。比如数据库并发太高无法承担了,我们一般会执行以下几个步骤:

      1. 增加Redis之类的缓存工具,将原本是物理数据库的一个问题拆解成2个子问题,并分别去解决对应的更多问题。
      2. 横向按字段拆表,将一些频繁更新的字段独立到独立的表去以关联的形式存在。
      3. 纵向按照数据业务特征(例如时间)分区数据。
  3. 敏捷开发与敏捷基础设施:在康威定律中已经解释了敏捷开发(迭代开发)对于微服务架构的重要性。说白了敏捷开发就是一种流程规范外加一些适合与流程规范的工具,比如GitLab、Jira之类的工具等被称为敏捷基础设施,敏捷工具和方法众多,比如每日站会、卡片式任务等等,这需要根据团队的需要和结构因地适宜。

  4. DevOps:DevOps(Development、Operations)并没有指定具体的技术实现,他就是一个从软件开发到产品上线发布的流程规范,只不过这个流程现在有大量的工具为我们提供支持。流程包括:

    1. 需求管理。
    2. 编码开发,单元测试(Junit、Jest白盒测试)。
    3. QA(黑盒测试)。自动化测试(Server walker)、代码质量监控(Sonar、EsLint)、接口测试(Jmeter、Loadrunner)。
    4. 上线发布运维。包括压力测试、多节点的运维管理、以及Cloud Foundry, Kubernetes, Apache YARN, and Apache Mesos等云平台的使用。

    这其中每一个过程都可以写成一本书。本人比较推崇CMMI的敏捷模型配合各种工具来使用。

  5. CI(Continuous Integration)/CD(Continuous Deployment):个人理解CI/CD应该属于DevOps的范畴,他的核心关注点在程序员代码交付和缺陷测试之上。我们知道在任何时候,技术开发人员和测试人员都应该是密切配合的,一个迭代周期之内应该是开发推进测试,测试驱动开发。并不用把这个过程想象得太复杂,实际上可以用Jenkins相关的各种插件实现代码持续集成、自动化检测、测试环境持续发布上线。

  6. 更多内容:除了以上几点,Cloud Native还涵盖了对一些细节的描述,比如分布式事物(最终一致性、容错性、可用性、缓存与实体同步)、弹性伸缩等

你可能感兴趣的:(cloud)