为什么
微服务不是十全十美的，不是银弹，是什么原因导致必须要做微服务划分，是否有足够的动机支撑，是项目需要，还是领导的想法，公司层面是否有相应的规划。
拆分后的服务谁来维护，研发同学是否愿意参与
为什么，思考清楚了，接下来看还需要考虑怎么做
单体应用的不足
- 随着时间推移逐渐变大，难以维护。
- 降低开发速度，应用越大，启动时间越长。
- 不同模块发生资源冲突时，扩展困难。密集计算型模块与密集I/O型模块资源冲突。
- 可靠性难以保障，任何一个模块的bug都有可能拖垮整个服务
- 采用新架构或者新技术非常困难
以上是单体服务面临的一些问题，但是不止于此。
微服务优点
微服务的核心价值在于以下几点：
- 粒度小，单个服务可以紧贴业务快速迭代；
- 去中心化组织和部署结构，减少不必要的协同；
- 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性；
- 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
- 服务本身的独立部署能力使得容错和容量弹性最大化；
- 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。
微服务缺点
- 微服务应用是分布式部署，需要考虑服务间的协作通信
- 微服务的数据库是分区的，需要考虑数据一致性问题，强一致性的场景，还需要引入三方解决方案，推荐最终一致性。
- 测试一个基于微服务架构的应用也是很复杂的任务，需要启动所有相关联的服务
- 微服务架构模式应用的改变将会波及多个服务。一个小需求，可能需要修改A、B、C三个服务。
划分粒度
划分微服务的粒度不仅需要考虑研发资源，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。
参考阿里的粒度：人均服务数是 1.5 个左右，建议维护一个核心服务 变更较少的服务。
划分原则
- 横向划分
- 基础工具类
- 通用服务能力
- 独立jar
- starter封装
- 上下游解耦
- 纵向划分
- 业务维度
- 基础设施模块
- MQ
- 缓存层
衡量指标
- 稳定性
- 性能
- 可扩展性
- 可维护性
改造成本
微服务改造是持续迭代的工程，需要考虑：
- 机器资源，包括部署主机、数据库
- 运维资源，大量微服务依赖自动化部署
- 研发资源，需要投入研发资源迭代新需求
- 基础设施的支持能力
- 沟通成本，部分需求带来的服务间协作
- 数据迁移成本，老数据迁移问题
- 原有组织或者研发变更成本
微服务基础设施
常用的一些微服务基础设施有：
- 注册中心
- 服务间通信
- 熔断降级
- 负载均衡
- 配置中心
- 定时任务
- 服务监控&告警
- 服务间链路追踪
- 日志平台
- CI/CD
- 自动化测试平台
关于技术选型：
- 【1-6】一般考虑Springcloud全家桶
- 【7】一般是Prometheus grafana，
- 【8】一般考虑Skywalking
- 【9】一般是ELK
- 【10】一般是自建或基于开源方案二次改造
- 【11】一般自建
选型方案，最终都需要综合考虑，比如研发人员的熟悉程度，是否有足够的研发资源和价值去自研。
也可以直接上云，现在的云服务厂商基础设施都很完善。
参考
Introduction to Microservices
Microservices in Production
Microservices AntiPatterns and Pitfall
