对微服务的认知与思考
什么是微服务
Loosely coupled service oriented architecture with bounded contexts.
松散耦合的、面向服务的、基于有界上下文的。
- 一组基于业务划分的服务
- 独立的进程
- 服务间轻量级通讯机制
- 独立技术栈
- 独立研发、部署
- 无集中式管理
- 微服务是一种架构风格
理解
基于微服务的概念与期望解决的问题，对微服务的理解：
- 它将传统的单一系统按照业务划分成不同的服务，服务之间互相协作、配合，为用户提供最终价值
- 每个服务运行在独立的进程中，服务与服务之间采用轻量级通讯机制相互协作（通常是基于HTTP协议的RESTful API）
- 每个服务围绕具体的业务来构建，并且能够独立的部署到生产环境中
- 很少有集中式的服务管理，每个服务可以使用不同的开发技术，使用不同的存储技术
与单体应用区别
单体特点
- 集中式设计、研发、部署
- 资源利用相互影响，如某个业务模块资源需求很高必须要通过提升整体资源配置来解决，反之亦然
- 需求迭代与维护成本随应用规模扩展“指数”提升，如某业务模块需求变更，需应用整体更新
- 稳定性差，很可能一个小的问题导致整个系统不能正常运行
- 开发效率低：代码的迭代更新造成的冲突等问题会频繁发生，且随着项目规模的增长更加突出
- 可扩展性较低：很难应对高并发、高可扩展要求
微服务特点
如概念与理解所述，可很好的解决单体应用的特点带来的弊。
微服务的利弊
任何事情都有两面性，在享受或者实现微服务带来的优势同时，也必须要面临以及解决微服务带来的挑战：
利
- 强模块化边界：系统中的不同功能模块拆分成多个不同的服务，每个团队负责自己的模块
- 可独立部署：每个服务都运行在自己的进程内，在部署上有稳固的边界，这样每个服务的更新都不会影响其他服务的运行，由于是独立部署的， 我们可以更准确地为每个服务评估性能容量，通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估
- 技术多向性：分散式治理，支持多种语言与技术（实际过程中非特殊需求不建议无限制扩展，技术多样性同样伴随着学习成本与通用性）
- 系统稳定性，高可扩展性：分布式技术带来的优势。
弊
- 接口的一致性：如何应用各种情况下接口的表现不一致问题，如重复调用等
- 分布式复杂性：如分布式事务、数据一致性、分布式锁、服务的治理、服务的监控等等。
- 运维的新挑战：如何实时、有效的监控整个应用，如何合理有效分配资源，如何跟踪、定位、发现问题等等
- 测试复杂性：需要很多团队联合集成测试
思考
微服务架构与单体应用架构该如何选择？
选型没有统一的标准或者条件，肯定是结合公司或者部门的现状、目标以及微服务与单体应用的特点来抉择，有的时候甚至可以存在的单体向微服务的转型或者改造。
- 初创型公司：单应用优先。初创型公司首验证商务模式，业务领域不是很清晰，微服务前期投入大，复杂性高
- 大型公司：微服务。业务成熟，单块应用不满足需求
- 发展中如何取舍：单块优先，随着业务领域清晰、一步一步转向微服务，根据业务将对应模块从单块应用抽出来独立为服务
如何实施？
- 技术选型？
- 组织架构调整？
- 团队划分？
- 业务梳理？
- DevOps强推？