微服务分享

• 小而专注
• 高度自治

• 逐渐变大, 几年后变成巨大怪物
• 开发团队痛苦, 敏捷开发和部署举步维艰, 任何单一开发都不可能搞懂, 团队士气走下坡
• 降低开发速度, 启动时间加长
• 复杂而巨大的单体式应用也不利于持续性开发
• 单体式应用在不同模块发生资源冲突时，扩展将会非常困难
• 可靠性降低, bug, 内存泄露将相互影响
• 单体式应用使得采用新架构和语言非常困难

• 单个服务很容易开发、理解和维护
• 技术异构性
• 易于独立部署, AB测试，持续化部署
• 每个服务独立扩展
• 与组织结构相匹配, 属主意识明确

• 微服务应用是分布式系统，由此会带来固有的复杂性
• 因为数据分区, 也因为CAP理论, 微服务不得不使用最终一致性方案, 因此对开发要求更高
• 单体应用容易测试, 微服务测试复杂度提高, 需要各个微服务的stubs
• 改动的影响将波及很多应用, 不过这是面向服务架构的特点
• 服务拆分后, 服务增多, 部署难道和工作量增加

• 根据业务边界来确定服务边界
• 如何寻找平衡, 如何取舍
• 分解技术
• 集成技术
• 注意服务与团队结构的关系

任何组织在设计一套系统时, 所交付的设计方案在结构上都与该组织的沟通结构保持一致

• 每个微服务暴露的细粒度API数量的不匹配, 客户端(移动端或者PC浏览器)需要发起多个(甚至数百个)服务请求, 在公网上效率非常低, 客户端代码非常复杂
• 微服务的协议可能并不是web友好型。
• 很难重构微服务: 随着时间推移, 服务可能合并或者拆分, 如果客户端直接与微服务交互，那么这种重构就很难实施.

• 封装内部系统架构, 提供API给各个客户端

• 授权, 监控, 负载均衡, 缓存, 请求分片, 请求转发, 协议转换, 管理, 静态响应处理

• 优点

  • 封装应用内部结构, 减少了客户端与服务器端的通信次数，也简化了客户端代码

• 缺点

  • 必须要高可用, 必须开发,部署和管理 (额外成本)
  • 可能成为系统的一个瓶颈

• 优势(ACID)

  • 数据持久化
  • 并发: RMDB 使用事务控制并发; 事务执行失败可以回滚
  • 集成: RMDB可以做为"共享数据集成"提供给多个应用使用, 达到数据共享; 同时RMDB有并发控制机制.
  • 标准模型: 各种RMDB大同小异

• 不足

  • 阻抗失衡
  • 集群扩展能力弱