微服务架构
单体架构能够很好地应对简单的业务系统。但是随着业务的扩张,功能的不断增加,单体架构面临着越来越多的挑战:
维护成本增加
- 团队越来越大,相应的沟通成本、管理成本、人员协调成本显著增加。
- 引起缺陷的原因组合多,导致分析、定位、修复缺陷的成本响应增高。
- 在自动化测试机制不完善的情况下,易导致“修复越多,缺陷越多”的恶性循环。
交付周期长
代码编译、检查,运行测试、构建、更能验证等,反馈周期变长。
新人培训周期长
对于新加入团队的成员,需要花更多的时间了解熟悉业务、配置环境、熟悉代码。
技术选型成本高
单体架构倾向于采用统一的技术平台或方案来解决所有问题。
可伸缩性差
- 无法按需伸缩。
- 资源有效利用率低。
构建全功能团队难
应用程序的复杂结构也会逐渐映射到研发团队的结构上。
微服务架构(Microservice Architect):
微服务架构是一种架构模式,它提倡将单块架构的应用划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。
每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通。
每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。
另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应更具业务上下文,选择合适的语言、工具对其进行构建。
本质特征:
服务作为组件
围绕业务组织团队
关注产品而非项目
技术多样性
业务数据独立
基础设施自动化
演进式架构
优势:
边界性
- 业务独立
- 功能耦合度低
独立性
- 独立部署
- 按需伸缩
技术多样性
- 使用合适的语言或者工具
- 使用合适的数据存储
挑战:
分布式系统的复杂度
- 网络因素(带宽、超时)
- 数据一致
- 可用性
微服务测试
- 测试策略
- 自动化测试
运维成本高
- 环境配置
- 部署
- 监控
微服务的依赖管理
- 版本管理
- 服务依赖
- 服务治理
资料来源:
http://www.cnblogs.com/Erik_Xu/p/6241359.html
http://www.infoq.com/cn/articles/analysis-the-architecture-of-microservice-part-01