应用服务化之后面临的挑战：
1）跨团队协作问题：服务变多之后一般会分小组开发，涉及跨团队联调，如何快速找到开发者 ？ 当前系统提供了那些服务，服务接口定义和参数是什么？服务使用示例，注意事项和约束是什么？开发完成之后调试，消费者A和服务提供者S进行联调会存在2个问题：a. 提供者S分布式部署，存在多个服务实例，路由动态分发，没办法确定会路由到哪一台服务器 b.若打断点，其它的消费者可能也正在使用，调试会被干扰，需要通知所有的开发者不要调用服务S，有点儿不太现实
2）服务的上下线管控：由于服务的发布很简单，上线会越来越随意，导致有时候架构师都不知道上线了什么服务，甚至出现重复服务，而服务下线比上线还要困难，因为业务调整，需要 结束某些服务的生命周期，服务提供者有时会直接将服务下线，导致依赖该服务的应用不能正常工作，应该是先将该服务标识为过时，然后通知调用方尽快修改调用，通过性能KPI接口和调用链分析，确认没有消费者再停用服务
服务安全：针对内部应用，服务框架常采用长连接管理客户端连接，针对非信任的第三方应用，或者而已消费者，需要具备黑白名单访问机制，防止客户端非法链路过多，占用大量的句柄，线程和缓存资源，影响服务提供者的质量
服务高SLA保障：业务高峰期，系统资源会成为瓶颈，需要对非核心服务 eg 用户评论、粉丝管理、积分管理等服务做限制，保障核心服务的正常运行，服务框架需要考虑如何关停非核心服务又不影响其它的合设服务
快速定位故障：服务化之后一个业务流程底层可能涉及成千上百的服务调用，任何一个服务发生故障都可能导致业务不可用，由于分布式部署，部署在成千上百台机器上，若仍使用原来的故障定位手段效率会非常低，服务化带来的价值也会大打折扣
服务治理非目标：
1）防止业务架构腐化：通过服务注册中心对服务强弱依赖进行分析，结合运行时服务调用链条分析，梳理不合理的依赖和调用路径，优化服务架构，防止代码腐化
2）快速故障定界：通过Flume等分布式日志采集框架，实时收集调用链日志，服务性能KPI数据，服务接口日志，运行日志等，实时汇总和在线分析，集中存储和展示，实现故障的自动发现，自动分析和在线条件检索，方便运维和开发人员进行快速问题定位
3）服务微管控：较细粒度的进行运行期服务治理，包括限流降级，服务迁入迁出、服务超时控制、智能路由, 统一配置、优先级调度和流量迁移等，提供方法级治理和动态生效功能，通过一系列的细粒度的治理策略，在故障发生时可以多管齐下，在线调整，快速回复业务
4）服务生命周期管理：包括服务的上线审批、下线通知，服务的在线升级以及上下线的服务文档库的建设
常见的服务治理：
服务降级、服务流控、服务动态扩展、超时控制、优先级调度、负载均衡策略调整、分组调整、等