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

2017 Page

5 of

31 系统、开发语言、数据存储还是工具,都是兼容的.也就是说,微服务是 多语种 的. ? 黑盒子:微服务中的服务都是按照 黑盒 设计的,也就是说,它们将内部 逻辑对外隐藏进来,各个服务间通过定义良好的 API 进行通信,避免了暗 含的相互依赖. ? 谁构建,谁运行:通常情况下,在生产环境中,构建了某个服务的团队负责 该服务的运行和维护.这条规则也称之为 DevOps2.DevOps 除了能让各个 团队按照自己的安排独立工作外,还可以让开发人员更贴近软件产品的真正 使用者,能帮助他们更好地了解用户的需求.微服务对于企业组织架构上的 影响也是不容忽视的,正如康威定律所言,系统架构是公司组织架构的反映 3. 图1:微服务架构的特征 单体型架构 vs. SOA vs. 微服务架构 技术为业务而生,架构也为业务而出现,无论传统单体型架构、SOA 和微服务都 是因为业务的发展而出现.出现 SOA 以及微服务框架与业务的发展、平台的壮大 密不可分. 单体型架构 当网站或者应用流量很小时,只需一个应用,将所有功能都部署在一起,以减少部 署节点和成本,简化开发流程,适合于个人开发或者小团队开发一些功能单一的小 产品使用.这是最传统的架构模式,一般整个系统都是有一个统一的数据中心,各Amazon Web Services C EC2 Container Service 上的微服务架构 May

2017 Page

6 of

31 个功能模块显式进行相互依赖(比如直接调用模块公开的方法).当网站流量随着 业务发展不断变大时,这种架构的应用在可扩展性、容错性(一旦某个功能模块被 流量击溃,整个系统瘫痪)上存在致命性的缺陷. SOA 当网站或者应用流量变大,单体型架构无法招架之时,可以采取面向服务架构方 式,将应用根据系统维度、功能维度、读写维度或者模块维度进行划分成各个独立 的服务组件,服务组件间通过某个约定的方式(比如 Web Service 或者 HTTP REST API)进行通信.当服务越来越多,容量的难以准确评估,小服务导致资源 浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量, 提高集群利用率,这种架构一般仍然存在一个统一的数据中心或者调度中心.整个 系统的可维护性、可扩展性相对于单体型架构得到提高,但在服务细粒度、隔度 性、去中心化方面仍与微服务有差,另外就是 SOA 架构常常依赖于总线结构,利 用可热插拔的中间件以及消息队列来完成服务与服务之间的解耦,对于总线结构的 依赖也使得服务的独立性并没有被完全剥离. 微服务架构 在微服务架构中,每个服务都要去中心化,不存在单点故障问题.每个服务都要实 现高可用、高负载,不会因为一个服务不可用而影响整套业务流.每个服务细粒 度,专注于自己的问题域,与别的服务采用更好的 Restful 或者良好定义的 API 进 行通信.服务都要高度通用化,即多种终端都可调用,不分语言和平台服务部署或 升级简单,不会消耗大量人力并且部署过程不易出现人为错误,同时还具有快速注 册与自动服务发现功能. 微服务的益处 许多 AWS 客户选择微服务架构来解决传统单体型架构中存在的敏捷性和可扩展性 限制的问题.让我们来看看选择微服务架构能够带来哪些方面的益处吧. 敏捷 使用微服务的组织由多个负责运维独立服务的小团队组成.各个团队都是在界限明 确的小范围内独立、快速地工作,从而起到减小迭代时间的效果.各个小团队效率 的提升将使整个企业组织工作效率进行很大程序地提高. 图2标示由多个小团队组成的企业组织架构与由一个大团队组成的企业组织架 构,在发布部署一个应用时的工作效率区别. Amazon Web Services C EC2 Container Service 上的微服务架构 May