微服务架构：微服务化后系统架构要如何改造？
随着业务功能的增加，当前系统依赖资源的扩展出现问题，一体架构在研发正本，部署成本上带来问题时，考虑将一体架构做微服务化拆分。
在对服务进行拆分的过程中，需要考虑的问题：
- 服务拆分要遵循哪些原则
- 服务的边界如何确定
- 微服务化后会带来哪些问题，如何解决这些问题。
1 微服务拆分的原则
1.1 单一服务内部功能的高内聚和低耦合
每个服务只完成自己职责之内的任务，对于不是自己职责的功能交个其他服务来完成
1.2 需要关注服务拆分的粒度，先粗略拆分再逐渐细化。
拆分初期可以把服务粒度拆得粗一些，后面随着团队对于业务和微服务理解的加深，再考虑把服务粒度细化
1.3 拆分的过程，尽量避免影响产品的日常功能迭代
一边做产品功能迭代，一边完成服务化拆分
1.4 服务接口的定义要具备可扩展性
服务拆分之后，各个服务的通信变为了网络请求，在定义接口的参数时，参数类型最好是封装类，这样添加参数就不必变更接口了，只需要在封装类中添加字段就好了。
2 微服务带来的问题和解决思路
微服务是一种架构手段，有效拆分可以帮助实现服务的敏捷开发和部署，但微服务是通过网络通信的分布式服务，如何在分布式环境下协调多个服务正常运行，引入了一定的复杂度。
- 服务接口间调用变为了跨进程的网络调用
- 多个服务之间有着比较复杂的依赖关系
- 一个服务依赖多个其他服务同时也会被其他服务所依赖，一旦一个服务性能出现问题，可能会影响其他服务。需要引入服务治理体系和对出现问题的服务进行熔断、降级、限流、超时控制等方法
- 服务拆分后，一条请求的调用链路上涉及多个服务，一旦这个请求的响应长或者出错，很难快速定位问题，需要引入分布式追踪工具，服务端监控来解决。