云源生（Cloud Native）

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

对于云技术（微服务）而言，2013年是一个分水岭，在这之前有一些零散的分布式应用的意识，但是没有一个系统性的概括。然后在2013年Matt Stine的Cloud 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）

      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还涵盖了对一些细节的描述，比如分布式事物（最终一致性、容错性、可用性、缓存与实体同步）、弹性伸缩等