PDF《EC2 Container Service 上的微服务架构》

2017 Page

7 of

31 图2:部署微服务 创新 小团队可以独立自主地针对自己负责的问题域选择相关的技术、框架和工具,这就 是创新的体现.职责与义务,让团队产生对自己的服务的责任感. DevOps 通过将开发与运维人员结合到一个团队中,让他们能更早地、更好地沟 通,解决了开发部署过程中没必要的摩擦和矛盾.当应用程序部署时,敏捷的处理 流程可以让开发和运维工作不再需要暂停下来,相反,整个软件交付周期,从提交 代码到发布版本,整个流程将变成自动化的.测试一个新的想法,或者当新功能出 现问题时及时回滚,将变得更加轻松.因为失败成本的降低,团队将更加乐于更改 和创新. 质量 使用微服务架构您的应用程序,将一定程度上提高代码质量.这跟面向对象设计中 提出的分模块开发有同样的效果:提高代码的可重用性、封装性和可维护性. 伸缩性 细粒度解耦的微服务架构另一个好处就是,它非常适合构建大规模系统.它允许针 对不同的服务选择最适合的技术,这也是性能优化的体现.每个服务都可以使用最 合适的开发语言和框架来实现,利用最优的数据持久化解决方案,并通过各自独立 的服务配置进行调优. Amazon Web Services C EC2 Container Service 上的微服务架构 May

2017 Page

8 of

31 合理解耦的微服务架构,可以独立地进行水平伸缩扩展.这相对于传统架构中使用 的垂直伸缩有很大的优势.垂直伸缩指的是当业务量、流量增大时,升级硬件资 源,将应用部署到 更大的机器 上,这会导致 机器硬件资源上限 和伸缩时宕 机的问题.水平伸缩,通过将更多的服务部署到服务池(多个机器组成的集群) 中,可以动态地适配流量,并且不会陷入单个机器资源上限问题.整个水平伸缩的 过程将会是自动化的.另外,应用程序的可靠性将得到增加,因为出现问题的服务 可以自动地被健康的服务替换掉,而不影响整个应用的运行. 可用性 微服务架构可以轻松实现故障隔离.通过健康检查、缓存、隔离仓、断路器等技 术,可以减小当某个组件出现故障时的影响,从而保证应用的高可用性. 微服务架构面临的挑战 尽管拥有前面提到的那么多优点,但是微服务架构和所有其他架构一样,都不是解 决所有问题的 银弹 .使用微服务架构也会面临一些挑战和难题.比如: ? 微服务架构都是分布式的,也就会存在所有 分布式计算误区 中提到的问 题4. ? 从单体型架构迁移至微服务架构,需要您准确地划分好各个服务间的界限, 并且从应用层到数据库层松耦合代码依赖. ? 除此之外,在组织管理方面还存在着一些挑战,比如如何组建一个高效的团 队,如何将团队转变成 DevOps 的生产模式,如何合理化开发团队与运维团 队的沟通等. 本白皮书主要关注的是架构和运维方面遇到的挑战,如果想了解更多关于 AWS 如 何运用 DevOps 的知识,请访问 https://aws.amazon.com/devops5 架构复杂度 在传统单体型架构中,所有的复杂度和依赖都存在项目的代码库中.而对于微服务 架构而言,复杂度变成了各个服务间的交互. 在架构上面临的挑战有处理异步通信、连锁故障、数据一致性问题、服务发现和授 权认证等问题. Amazon Web Services C EC2 Container Service 上的微服务架构 May

2017 Page

9 of

31 运维复杂度 运用微服务架构,你不再只是运行一个服务,而是数十个,甚至数百个服务.这也 就带来了以下问题: ? 如何以可伸缩、低成本的方式配置好所需要的资源? ? 如何避免不同的团队重复 造轮子 ,重复处理同一个问题,或重复安装配 置相同的软件工具? ? 如何跟踪并管理好上百个代码流的部署过程和它们之间的相互依赖(不同服 务可以单独部署)? ? 如何监控整个系统的健康并提前感知潜在的热点和流量高峰? ? 如何在整个系统各个服务间追踪和调试问题? ? 如何分析一个快速增长并超出预期需求的分布式系统的海量日志数据? ? 如何处理不同技术栈、开发环境间缺少统一标准的问题? ? 如何受益于不同技术带来的开发效率,而不受困于维护升级这些技术带来的 困难? 微服务与云平台 微服务近些年的崛起........