作为一种架构模式，微服务将复杂庞大的业务系统切分为数十个乃至数百个小的服务，每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改，并带来了语言和框架选择灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。
单体架构跟微服务架构区别
微服务改造策略：
微服务改造的过程其实就是将原有的单体架构改造成微服务架构的过程，微服务改造是一个漫长的过程，需要充分考虑遗留系统的情况，在改造的过程中原有的遗留系统跟改造后的微服务系统需要共存很长一段时间，基于不同的规模改造所需要的时间从几个月到一两年甚至数年的时间不等。目前微服务的改造的常见策略可以分为二种：
1. 绞杀模式：绞杀者策略是一种逐步剥离业务能力，用微服务逐步替代原有单体系统
的策略。它对单体系统进行领域建模，根据领域边界，在单体系统之外，将新功能和部分业务能力独立出来，建设独立的微服务。新微服务与单体系统保持松耦合关系，随着时间的推移，大部分单体系统的功能将被独立为微服务，这样就慢慢绞杀掉了原来的单体系统。绞杀者策略类似建筑拆迁，完成部分新建筑物后，然后拆除部分旧建筑物通俗的来讲类似“从农村包围城市”。
2. 修缮模式：修缮者策略是一种维持原有系统整体能力不变，逐步优化系统整体能力
的策略。它是在现有系统的基础上，剥离影响整体业务的部分功能，独立为微服务，比如高性能要求的功能，代码质量不高或者版本发布频率不一致的功能等，通过这些功能的剥离，我们就可以兼顾整体和局部，解决系统整体不协调的问题。修缮者策略类似古建筑修复，将存在问题的部分功能重建或者修复后，重新加入到原有的建筑中，保持建筑原貌和功能不变。一般人从外表感觉不到这个变化，但是建筑物
质量却得到了很大的提升。
微服务改造关键要素：
微服务改造的过程有二个关键点：1. 微服务设计规划；2. 遗留系统迁移规划； 微服务设计规划：微服务设计规划中从大到小的范围又包含二个关键步骤：业务拆分、技术实现；业务拆分主要是指针对原有的业务系统进行业务层的梳理，基于业务层面来看哪些功能应该放到同一个服务，哪些必须分开，从而实现庞大的单体系统的拆分，最终保证微服务与微服务之间的高内聚、低耦合。目前常见的实现方式比如：基于事件风暴的方式进行业务流程梳理。技术实现是指基于业务梳理的微服务拆分结果进行微服务开发，其中就包含用何种开发语言、框架、中间件、开发模式等。
遗留系统迁移规划：遗留系统迁移规划主要是指将企业遗留系统平稳的向微服务过渡，其关键点是实现核心业务、高并发业务、低容错业务从遗留系统无缝的迁移到微服务架构，此部分内容一般都会先选取试点项目，基于试点项目进行实践，从而总结出一套适用于企业自身的最佳流程或者实践，然后再大规模的组织内推广，从而真正实现遗留系统的微服务化改造。
微服务改造实施步骤：
如何进行微服务改造，微服务改造具体步骤是怎么样的？我们基于部分项目的经验总结如下，当然并不一定适应于所有的业务场景，正如前面所说每个企业的业务场景、各种环境因素各不一样，所以还是要具体问题具体分析，微服务改造实施计划如下：
1. 选取业务领域：微服务改造不是一蹴而就的，一般会先选取部分业务场景作为改造
试点从而总结成功的流程和最佳实践，至于业务场景的选择说法各异，有的推荐从边缘业务开发，这样的风险较低，但是也有可能看不到明显效果从而导致整体改造过程停滞不前，有的推荐从核心业务开始，这样效果最明显但是风险相对较高，各有优缺点，看改造决心和当前系统“痛”的程度，也可以参照“绞杀”、“修缮”。等模式进行业务领域选择。
2. 建立统一目标、愿景：基于公司的整体目标，针对业务领域建立统一目标、愿景，
让大家都能清晰知道，所有人朝着同一个目标进行。
3. 遗留系统分析（业务拆分）：微服务规划阶段前，团队需要了解业务知识，改造遗
留系统前，团队首先要学习遗留系统知识，为迁移做准备。针对业务领域进行整体
的业务流程梳理，结合业内领域驱动设计方式，以事件风暴的实践进行，常见的步骤如下：1. 识别事件，2. 识别命令，3. 寻找聚合，4. 划分子域和界限上下文，5. 微服务划分
4. 制定迁移策略和路径：综合管理、业务、技术等因素，为遗留系统微服务架构升级
制定迁移策略和实施路径。
5. 技术选型和基础设施建设：基于公司的总体目标架构，根据系统分析结果、迁移策
略和路径以及遗留系统现状，选择微服务基础设施和技术组件，如：SpringCloud、ServiceMesh、Docker、K8s……等等。
6. 团队规划、赋能：进行微服务开发团队规划，结合康威定律，根据服务、架构的方
式组建相应的团队，各微服务开发团队是自组织、自管理的团队。同时针对团队成员进行新的技术架构、框架、开发方式方法进行赋能，确保后续步骤的顺利进行。 7. 迭代交付：微服务开发过程通常结合敏捷开发、DevOps等前沿理念进行，通过敏
捷开发、DevOps工具链加速整个微服务的开发过程，保证开发质量。
8. 总结项目经验，沉淀最佳流程和实践：基于项目实施过程总结沉淀出适合企业自身
的最佳改造流程、规范、最佳实践等，这一阶段是不断循环完善的过程。 9. 组织内推广微服务改造方式方法
实践案例：
该项目是某全球领先的大型营养和健康管理公司，其现有业务受到传统技术架构限制，
存在诸多问题，之前系统是一个庞大的单体应用，对接第三方系统较多，开发语言各不一样， 经过了多年变化，IT团队为了满足之前大型集团的业务需要已经举步维艰，响应跟不上业务的变化。
我们基于微服务、容器、DevOps等云原生全栈技术帮助客户建立了技术中台，基于我们的微服务平台实现服务注册发现、服务限流、服务路由、服务鉴权、服务熔断等一系列服务治理能力的同时，为企业业务应用也提供全生命周期的管理，包括容器部署、虚拟机部署等用户自定义IaaS层资源的能力；除此之外，在服务框架层面我们既兼容了Spring Cloud和Dubbo两种常见的微服务框架，也兼容Istio的Service Mesh能力，用户只需要在开发时引入相应的SDK或者Jar包，即可开发自己的业务应用。基于技术中台帮助客户建立了业务中台，从而实现技术与业务的双向联动，整体架构如下图：
我们采用DDD方法、事件风暴实践对该企业业务进行重新梳理，采用微服务架构按业务领域进行划分，建设全新业务系统，业务迁移采用微服务的绞杀者模式逐步对频繁变化的业务优先绞杀迁移到新平台，逐渐迁移，直到全到功能迁移到新平台。开发过程基于敏捷开发的理念进行快速迭代，同时通过DevOps工具链实现快速开发、简化微服务运维工作量。
改造前该企业原有库存业务各客户端没有统一服务化管理，APP端、小程序端各自维护，
导致库存频繁出现超卖、分配不均等业务问题，第三方系统对接时不得不对接多套已有系统等技术问题。我们帮助客户对其业务重新进行了梳理，重新设计了各业务微服务，统一了库存微服务化管理，打造了库存中台，APP端、小程序端共享库存中台微服务，入口收敛、业务实现了统一。最终有效防止了库存超卖、动态分配、全局共享等长期困扰客户的业务痛点。
库存业务架构图
关于我们：
安畅网络是中国市场专业的云托管服务商（Cloud MSP），在数据中心和云计算领域有近十年的专业交付和管理经验，目前正服务于2000多家企业级客户并与全球多家超大规模公有云服务商建立了战略合作关系。我们经过数年的探索，利用在云计算领域的丰富经验，成功实现了一套兼容各业务场景，具有集成Spring Cloud、Dubbo、Service Mesh等常见微服务解决方案能力的PaaS平台，其提供一站式应用全生命周期管理能力和数据化运营支持，提供多维度应用和服务的监控数据，助力服务性能优化
微服务改造的定义与步骤 - 图文
