系统微服务化，始于拆分，重在治理

一、 微服务架构的优与劣
微服务架构最近几年发展迅猛，尤其是从2017年以来在业界异常火爆。不论是基于云原生技术的新应用，还是已有的复杂单体应用，都在朝着微服务化的方向进行构建和改造。
　　微服务架构带来了很多好处，比如支持小团队快速迭代，引入的复杂度可控，支持独立的运维部署，可按照不同业务压力有针对性的扩缩应用实例，可灵活的组合各服务，支持采用不同的技术栈研发等等。
　　同时，企业在进行应用微服务拆分时也出现了很多问题。例如系统部署复杂度增加，服务间调用复杂，本地数据库事务无法保证整体数据一致性，服务依赖关系不够清晰，配置管理难度增大等等。
　　可见，微服务的引入有利有弊。如果不能有效的解决其带来的问题，反而会带来额外的负担。在本文中，我们一起分析下在微服务化拆分后，带来的各种问题以及相应的解决办法，同时一起来感受下微服务治理平台一站式解决方案带来的强大体验。

二、系统微服务化，始于拆分，重在治理
微服务并不是解决问题的“银弹”
如何针对原有的复杂单体应用进行合理的拆分，是应用微服务化需要考虑的第一件事。
　　微服务拆分带来了一系列的问题，比如：
　　1）服务间如何进行有效便捷的相互调用；
　　2）分散的日志与配置文件如何管理；
　　3）如何针对微服务特殊指标进行监控；
　　4）调用链路查看与服务依赖计算如何进行；
　　5）服务的稳定性如何控制；
　　6）数据的最终一致性怎样保证；
　　
这些问题中，甚至有些问题被认为是业界公认的难点。如何完美的解决这些难题，就是微服务治理平台需要面对的任务。
微服务拆分，要有自己的理论依据
　　微服务拆分，有其特殊的拆分原则和理论依据。按照这些规范拆分出的微服务应用，最终才能更加有效的组合在一起，发挥整体威力。
　　
　　面对复杂的业务架构时，DDD（领域驱动设计）理论和微服务拆分很好的结合在一起。它通过分层、领域模型、上下文、事件、聚合等，对业务系统进行设计、拆分；同时，我们也有康威定律、AKF等理论的支持。再有就是一些项目上的落地的实践经验，如《微服务7步设计法》等，也可以提供很好的借鉴。
　　通过这些理论依据和实践经验，可以帮助大家按照单一职责、小粒度、小团队等原则拆分服务，同时避免双向和循环依赖。但是只有这些理论基础是远远不够的，任何一个业务应用的微服务拆分，都需要和具体的业务场景相结合；其具体的拆分任务需要由系统使用者、业务架构师、技术架构师共同参与，合理的规划，避免纸上谈兵和过度设计。