微服务架构综述
1.1 什么是微服务架构
实际上,从业界的讨论来说,微服务本身并没有严格的定义。
ThoughtWorks的首席科学家——马丁·福勒(Martin Fowler)先生,对微服务的这段描述,似乎更加通俗易懂:
微服务架构是一种架构模式,他提倡将单一应用程序划分成一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务 之间采用轻量级的通信机制相互沟通(通常是基于HTTP的RESTful API)。每个服务都围绕这具体业务进行构建。
—— 摘自马丁·福勒先生的博客
1.2 微服务架构与SOA
SOA与微服务的区别
SOA实现 |
微服务架构实现 |
企业级,自顶向下开展实施 |
团队级,自底向上开展实施 |
服务由多个子系统组成,粒度大 |
一个系统被拆分成多个服务,粒度细 |
企业服务总线,集中式的服务机构 |
无集中式总线,松散的服务架构 |
集成方式复杂(ESB/WS/SOAP) |
集成方式简单(HTTP/REST/JSON) |
单块架构系统,相互依赖,部署复杂 |
服务能单独部署 |
相比传统的SOA的服务实现方式,微服务更具灵活性,可实施性以及可扩展性,其强调的是一种独立测试,独立部署,独立运行的软件架构模式。
综上所述,对于微服务的概念而言,他是传统SOA的定义的一个子集,而对于其实现方法而言,他是一种更符合现代互联网发展趋势的实践,是一种更容易帮助企业或组织有效并成功时间服务架构的实践。
2.3微服务的本质
微服务的本质特征通常包括如下几个部分:
1 服务作为组件
将应用模块化并为其构建相对的单元。传统时间组件的方式是隔离独立的部分或抽取公用的部分,构建共享库(Library),从而达到解耦和复用的效果。
2 围绕业务组织团队
为了节省成本,提高人员效率,企业或者组织一般都会根据技能划分团队。
微服务架构的团队组织方式不同于传统的团队组织方式,他提倡以业务为核心,按业务能力来组织团队,团队中的成员具有多样性的技能。
3 关注产品而非项目
亚马逊的CEO Werner Vogels曾经说过一句话,“You build it,you run it“。对团队而言,产品就是团队的,也是每个成员的,团队中的每个人都有责任,有义务确保产品的快速发展以及演进。
4 业务数据独立
倾向于采用统一的数据存储平台来存储所有数据。
优点:
- 能够随着业务的发展,提供业务数据接口集成,而不是以数据库的方式同其他服务集成。
- 能够随着业务的发展,选择更合适的工具管理或者建议业务理数据
5 基础设置自动化
6 演进式架构
2.4微服务不是银弹
- 独立性
- 单一职责
- 技术多样性
实际上微服务的实施过程中,需要考虑如下元素:
- 分布式系统的复杂度
- 性能
- 可靠性
- 异步
- 数据一致性
- 工具
- 运维成本
- 配置
- 部署
- 监控与告警
- 日志收集
- 部署自动化
- DevOps与组织架构