一：对微服务的认知与思考

微服务专栏地址

　　专栏：微服务
　　微服务系列总目录

目录

1 什么是微服务

Adrian Cockcroft

Loosely coupled service oriented architecture with bounded contexts.

松散耦合的、面向服务的、基于有界上下文的。

Martin Fowler

• 一组基于业务划分的服务
• 独立的进程
• 服务间轻量级通讯机制
• 独立技术栈
• 独立研发、部署
• 无集中式管理
• 微服务是一种架构风格

1.1 理解

基于微服务的概念与期望解决的问题，对微服务的理解：

• 它将传统的单一系统按照业务划分成不同的服务，服务之间互相协作、配合，为用户提供最终价值
• 每个服务运行在独立的进程中，服务与服务之间采用轻量级通讯机制相互协作（通常是基于HTTP协议的RESTful API）
• 每个服务围绕具体的业务来构建，并且能够独立的部署到生产环境中
• 很少有集中式的服务管理，每个服务可以使用不同的开发技术，使用不同的存储技术

2 与单体应用区别

2.1 单体特点

• 集中式设计、研发、部署
• 资源利用相互影响，如某个业务模块资源需求很高必须要通过提升整体资源配置来解决，反之亦然
• 需求迭代与维护成本随应用规模扩展“指数”提升，如某业务模块需求变更，需应用整体更新
• 稳定性差，很可能一个小的问题导致整个系统不能正常运行
• 开发效率低：代码的迭代更新造成的冲突等问题会频繁发生，且随着项目规模的增长更加突出
• 可扩展性较低：很难应对高并发、高可扩展要求

2.2 微服务特点

如概念与理解所述，可很好的解决单体应用的特点带来的弊。

3 微服务的利弊

任何事情都有两面性，在享受或者实现微服务带来的优势同时，也必须要面临以及解决微服务带来的挑战：

3.1 利

• 强模块化边界：系统中的不同功能模块拆分成多个不同的服务，每个团队负责自己的模块
• 可独立部署：每个服务都运行在自己的进程内，在部署上有稳固的边界，这样每个服务的更新都不会影响其他服务的运行，由于是独立部署的， 我们可以更准确地为每个服务评估性能容量，通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估
• 技术多向性：分散式治理，支持多种语言与技术（实际过程中非特殊需求不建议无限制扩展，技术多样性同样伴随着学习成本与通用性）
• 系统稳定性，高可扩展性：分布式技术带来的优势。

3.2 弊

• 接口的一致性：如何应用各种情况下接口的表现不一致问题，如重复调用等
• 分布式复杂性：如分布式事务、数据一致性、分布式锁、服务的治理、服务的监控等等。
• 运维的新挑战：如何实时、有效的监控整个应用，如何合理有效分配资源，如何跟踪、定位、发现问题等等
• 测试复杂性：需要很多团队联合集成测试

4 思考

4.1 微服务架构与单体应用架构该如何选择？

选型没有统一的标准或者条件，肯定是结合公司或者部门的现状、目标以及微服务与单体应用的特点来抉择，有的时候甚至可以存在的单体向微服务的转型或者改造。

• 初创型公司：单应用优先。初创型公司首验证商务模式，业务领域不是很清晰，微服务前期投入大，复杂性高
• 大型公司：微服务。业务成熟，单块应用不满足需求
• 发展中如何取舍：单块优先，随着业务领域清晰、一步一步转向微服务，根据业务将对应模块从单块应用抽出来独立为服务

4.2 如何实施？

• 技术选型？
• 组织架构调整？
• 团队划分？
• 业务梳理？
• DevOps强推？