实践“云原生”互联网应用 | how to build cloud native applications

Editor's Notes

• #2: 云原生和微服务架构的专场，&& 分享的话题：如何实践云原生和微服务，开发互联网应用……
• #3: 实现云原生应用，有12要素 12要素描述云原生应用具备的特征，还有为了实现这些特征，可以参照的12项实践指南 它涵盖了管理代码、依赖、配置， 组织开发过程， 如何部署、监控及操作等方面。全面、精辟、有效。时间因素不展开讲， 建议登录 12factor.net 阅读这些实践的详细介绍。采用“云原生”的实践让我们更容易开发、测试和部署应用 “云原生”是开发互联网应用的最佳实践。为什么？ 因为实践12要素的云原生应用。……帮我们更快、可靠、易于扩展
• #4: 更快、可靠、易于扩展。 互联网环境下的快、是我们能够快速响应用户的反馈，快速实施创新(更快改需求，更快响应“需求变更”) 可靠的互联网系统，可以避免用户流失和防止SLA损失，让我们持续获得用户收益 易于扩展，使得我们可能快速扩展以获取更大收益，使得我们可以更有效利用投入，只为扩展买单。 快速、可靠和易于扩展， 才能帮助我们互联网业务，赢得竞争加剧的市场、日益重要的用户，以及赢得创新…… 首先谈可靠。关于可靠，我们真正想谈是什么？……提升可用率。
• #5: 什么是可用率？ 对于线上运行并且偶尔不可用的系统，可用率公式：分子是两次不可用之间的间隔=系统可用时间，分母是总时间=系统可用加上系统从不可用恢复到可用的时间。 系统不可用，通常有两种原因，系统正在发布更新，或者发生了线上故障。前者时机可控，后者不能，提高可用率，我们有两个方法…… 提高可用时间（减少发布次数）， 或减少不可用时间（更快从不可用恢复可用） 。对于这两种方法，我们说…… 降低每次发布导致的系统不可用 好于 减少发布次数（这样相同可用率下支持更多的发布次数，有更多机会满足需求和创新） 降低不可用时间，可以到多少？ 可以是0（即使在发布更新过程中，系统也保持可用）。怎么做？两种实现方式，建议大家去做个了解。 系统可以自动检测到故障，并且马上自动恢复过来，故障应该导致尽量短的不可用 当然……我们都不喜欢故障
• #6: 生活在这样的世界， 开发软件就会简单许多： 网络是可靠的， 延迟是没有的，带宽是无限的，网络是安全的，等等等等 可能吗？……不可能。 现实中各种故障总是 经常出现 / 难以预知 / 甚至不能避免， 啪！然后？（多米诺牌式的崩溃） 只能是这样吗？ ……不需要绝望 我们还有机会提前做准备 。怎么准备？……
• #7: 很多。 把他们归为三类：架构考虑，故障检测和处理，故障预防。简单来说，就是系统采用了这些做法， 就可能自动发现、隔离故障并自动恢复。 时间因素这次不展开，建议大家分别再去看看。跟大家分享一个例子……
• #8: 这是我们下单系统的一段Java代码。内容不多，相信大家都看懂。 第一，代码使用Spring Cloud中的Feign支持库，用非常简洁的语法产生到会员系统API的REST调用代理。 第二，它定义了在会员系统出现故障时，下单系统应有的行为：继续正常下单流程，只是将表单初始化为一个空白的默认地址。 这样，故障发生时，这段显式声明的降级代码将帮助我们，检测和自动隔离上游系统的故障，保持系统可用，提升了最终用户的体验…… 严于对己，宽以对人。设计一个健壮的分布式系统，都应该遵循这条法则。 妥善处理失败，是一个能够服务用户的线上互联网系统应有的行为， 一个系统，如果达到 “能够服务用户”这种状态，我们称之为“生产就绪”的系统。 ……
• #9: “生产就绪”的软件是如何被开发出来呢？ 观察传统软件过程的示意图，大家自行脑补软件生产线的其他环节：需求、交互、设计、开发、测试、部署、运维，等等 这是一个是按照“分层” 模型建立的多阶段过程，每个阶段专注一个层次的工作：软件在经历全部阶段之后，附加了每个层次上完成的特性，一步步从功能完成走向生产就绪，并最终交付到用户。这个过程非常利于规模化和专业分工，即使庞大复杂软件也能从这个过程被高质量交付出来。 唯一的问题，不能很快从头到尾经历完全部阶段。所以正在运作的生产线，每个环节总是堆积着大量的半成品：换句话说，你总是不能及时响应来自最终用户的任何反馈。 有没有其他做法？ 能不能直接就开发出“生产就绪”的软件？…… 我们对团队提出了挑战：它需要能力完成之前由多个角色执行的任务(让他们坐在一起吧)， 这个过程还可能会受一些约束。比如相对更容易在对小规模团队中组织，规模化会带来协调难度，同时不像上一个过程，它难以通过加大批次来提高产量。 好处呢？如果功能足够小，就可以很快完成，而一旦完成就直接服务到最终用户，开始获得收益…… 相对于上图这个推的模型，下图更接近一个拉的模型，所以我们总能快速响应来自最终用户的反馈，或者实施创新。因此这个DevOps交付过程很适合开发“生产就绪”的互联网产品，通过充分实施自动化，我们还可能进一步加速这个反馈循环。我们想象一下，一个个小的功能通过这个过程生产出来，直接交付到用户，并从用户反馈快速进入下一轮迭代周期，被完善或者被替代。通过这个过程逐步建立起整个互联网产品，会是怎样一个图景呢？……
• #10: 这是一个互联网产品：网易云容器服务的用户，金融事业部下众筹产品，在项目启动一个月后，整个产品线上系统架构。 现在刚刚上线第一版的网站，新功能正在路上（开发中）。然后…… 2. 第二月，新功能和新系统一起上线了，注意版本号代表了每个系统首次上线后经历的发布次数 四个月，又多了一些功能和系统 八个月，更多功能，更多系统。所有这些业务系统和基础服务都运行在网易云的容器服务中，面向互联网用户提供服务。 这是使用微服务来构建互联网产品的典型案例，它的建设过程有什么特点？ 一是随着项目进程，产品包含越来越多的功能和系统 二是不像拆房子：不是开发庞大复杂的单体架构再拆成多个服务；而是自始自终每个系统都保持简单 三也不是搭积木：不是开发每个服务然后合成产品才交付，而是从简单到完善，从一开始产品就要包含完整功能来支持业务开展。 自始自终保持完整，保持就绪，这正是实施微服务架构所瞄准的目标……
• #11: 上图是搭积木建立系统的方法，下图是我们采用的方法。 差异是什么？ 周期时间。 更长周期时间需要持续的成本投入、面临更大市场风险，以及产生更慢的反应速度。 所以面向产品而不是软件项目，保持就绪，自始自终面向用户可用，是建设一个互联网系统需要瞄准的目标。
• #12: 所以一个微服务应当是： 1. 面向产品的： 它应该自始自终面向用户可用 2. 易于替换的：易于替换带来更大的灵活性，从而支持快速创新 3. 自包含低耦合，不相互依赖同样也提高了灵活性 4. 围绕业务能力建立： 业务能力=内聚的一组相关功能，而功能才是软件变更的最小单位，围绕业务能力建立的微服务是实现低耦合的关键 5. 系统和每次变更都足够小，才能易于理解和实现，避免在更长的演化过程中架构逐渐腐化，变得臃肿复杂。…… * 计算机行业的先驱早就发现： 我们的智力擅长精通复杂的静态结构，却不擅长掌控过程的演化。这是为什么架构腐化总是发生……
• #13: 精通复杂的静态结构有一个万能方法-分层。 “分层”在软件行业里无处不在，他的最大好处：概念非常自然，能够帮助我们理解或设计复杂的系统结构（通过逐层处理获得简化，就像是分阶段的软件开发过程） 这是一个典型的分层系统，它有什么问题？ 如果出现故障。…… 我们看到因为分层依赖，导致了整个系统的崩溃。…… 通过 冗余 避免了单点故障， 容量规划又有难题，层次增加造成了负载模型复杂化，难以避免浪费并降低弹性，不过更大的问题。…… 每个功能横跨在层次上，就是发布三次才能完成一个功能。什么问题？慢。…… 良好设计的单体系统可以避免这些所有问题。图是来自facebook/cookie cutter扩展的示意 ，建议大家网上找文章看，相信会有启发 良好扩展需要避免层次依赖，设计分布式的微服务系统更是如此…… 如果两个服务总是要同时更新，他们就不是低耦合。所以在设计微服务时，不要再谈分层了，它帮不到我们。 ……
• #14: 实践微服务，有哪些提示和技巧呢？ 第一是放弃分层架构，刚刚讨论了。 第二是反思重用，要致力可替换，而不是重用，因为重用一般会带来耦合和僵化的设计、牺牲可用性。而相比面向功能设计，面向重用的设计需要数倍的投入并且难以改变（也可能因为之前沉没的成本，不愿改变）。 第三，不重用不代表不设计：良好抽象和设计的接口是实现易于替换的关键，反之亦然。我们要以保持接口稳定为原则实现接口演进。 第四，拒绝分布式环境下的ACID，可以让应用有机会采用更加自然、优雅的设计：BASE下的柔性事务，EDA（事件驱动架构），等等。 第五，快速部署……
• #15: 快速部署是云原生应用的最后一公里。非常关键，尤其对于微服务来说，面对越来越多服务数量，部署的次数和风险也成倍增加。 我认为必须实现快速部署，否则不应使用微服务。不然就是挖坑……
• #16: 为了实现快速部署，首先很多工作不应该只到 “部署阶段”才做，建议在开发互联网应用时： 考虑从一开始就实施持续集成，确保随时拿到可在线上部署的版本 可以用Docker统一交付物的打包格式。自包含、进程隔离的docker容器更易于测试、分发和运行，比如在一台机器上启动更多实例 最后是面向在云端部署来设计系统，这样可以充分利用云的这些优势满足应用扩展的需求。 在网易云我们还提供了各类PaaS，容器服务；以及大规格、网络增强型主机及高性能物理机容器等，充分匹配应用需求。什么叫面向云端部署来设计呢？（云原生）云的本意，不是把云作为基础设施/平台去依赖， 而是把云提供的基础设施及平台作为一个普通服务，参照其SLA去容错并实现应用的高可用（严于对己、宽以对人）。 做完这些工作以后……然后
• #17: 然后，我们运用自动化这个大杀器，加速我们整个开发流程：自动检查测试代码、自动打包部署、自动准备云资源，自动扩容、处理故障，等等。真正实现持续和快速的交付过程。 就软件部署、自动化应用等话题，之后马上有庆兵的分享继续探讨。
• #18: 快速回顾一下话题： 第一，实践12要素的云原生应用让我们更加快速、可靠、易于扩展，帮助互联网业务赢得创新和挑战 第二，打造高度可靠和生产就绪的系统需要我们为故障做准备； 第三，让微服务更快和易于替换，实践微服务需要反思传统的分层和重用等软件方法，关于微服务，之 最后，是实现持续和快速的交付过程，“最后一公里”这个话题。 今天晚些还会就微服务、持续交付、自动化部署等话题有深入讨论和实践分享话题，欢迎期待……