微服务重构的一些问题
微服务重构前猜测重构过程中可能遇到的一些问题。
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。- 康威定理
软件架构的最基本规律：架构是通过解决当前的需求和痛点而演进的，无法根据没有出现的问题和痛点进行设计。
技术问题和管理问题并不是两个问题，而是同一个问题的两个侧面。
整理汇总
2019-2-19 09:43:05
- 微服务技术栈如何选择
- 从哪里开始着手重构为微服务
- 微服务拆分规则是怎样的？如何判断一个模块应该拆分为微服务？
- 微服务的部署过程和策略是怎么样的？一次部署或上线需要多长时间？部署某个服务时不影响上下游的其他服务
- 微服务的安全问题怎么保障？
- 数据库如何设计？是否单独作为一个微服务，或每个服务单独访问数据库？
- (缓存，事务)在多个节点同时操作数据时，如何保证数据的一致性
- 内部接口的调用机制：同步/异步,HTTP/RPC,如何保证调用过程中的数据安全
- 日志的实现和管理方式：多个服务会产生很多日志文件？汇总/查看，
- 测试：如何做单个服务的灰度测试，测试系统自动化程度
- 上线后异常或性能问题如何定位？
2019年2月18日
- 采用微服务架构的驱动力，基于什么问题和痛点需要重构为微服务框架？重构的动机是什么？
- 那些问题和痛点，在重构为微服务之前做过什么哪些尝试与改进（读写分离/动静分离）
- 如何选择技术栈，或选择原则与基本方向
- 重构的起点，如何入手，从哪里开始，为什么从这里开始
- 采用微服务后，有哪些对开发效率影响较大的一些制度或规则
- 自动化测试与部署 方案
- 安全问题 如何保证
- 一个完整服务的卡顿问题如何定位
- 微服务之间的调用方式
- 微服务划分规则如何界定
- 按照组织结构来划分(人员)
- 按照功能模块来划分
- 依赖关系如何解决：两次实现/多次实现，还是1次实现，其他调用
- 开发人员的沟通问题：微服务拆分后，微服务业务开发任务如何分配给开发人员
- 重构过程中遇到的技术难题
太过具体，以后再说
- 是否涉及到过分布式事务问题
1、内部接口的调用机制（如何保证调用过程中的数据安全）
2、在多个节点同时操作数据时，如何保证数据的一致性
3、日志的实现方式（多个服务会产生很多日志文件）
4、服务部署的策略（即部署某个服务时不影响上下游的其他服务）
5、如何做单个服务的灰度
[1] 为什么微服务实施那么难？如何高效推进微服务架构演进 https://gitbook.cn/books/59870d65d115e231bf3e3f5f/index.html