微服务划分的思考
为什么
微服务不是十全十美的，不是银弹，是什么原因导致必须要做微服务划分，是否有足够的动机支撑，是项目需要，还是领导的想法，公司层面是否有相应的规划。
拆分后的服务谁来维护，研发同学是否愿意参与
为什么，思考清楚了，接下来看还需要考虑怎么做
单体应用的不足
随着时间推移逐渐变大，难以维护。
降低开发速度，应用越大，启动时间越长。
不同模块发生资源冲突时，扩展困难。密集计算型模块与密集 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】一般自建
选型方案，最终都需要综合考虑，比如研发人员的熟悉程度，是否有足够的研发资源和价值去自研。
也可以直接上云，现在的云服务厂商基础设施都很完善。
参考
版权声明: 本文为 InfoQ 作者【无心水】的原创文章。
原文链接:【http://xie.infoq.cn/article/e78d1f0abcd488a65b0799693】。文章转载请联系作者。
路漫漫其修远兮 2018.08.16 加入
熟悉Java，略懂Python
评论