漫谈何时从单体架构迁移到微服务？

面对微服务如火如荼的发展，很多人都在了解，学习希望能在自己的项目中帮得上忙，当你对微服务的庐山真面目有所了解后，接下来就是说服自己了，到底如何评估微服务，什么时候使用微服务，什么时间点最合适，需要哪些技术储备和资源投入等等，这些都是你需要面对和解决的。

本文从单体架构，微服务架构，微服务风险评估，微服务落地条件等几个方面探讨微服务的落地过程，希望对你有所启发。

　　讲解微服务之前，我们先简单了解下单体架构。

一、单体架构

　　

单体架构的优点：

• 快速开发和验证想法，证明产品思路是否可行

• 投入资源和成本，包括人力和物力相对比较节约

单体架构的缺点：

　　随着业务的复杂度增加，单体的灵活度会逐渐下降，比如：

• IDE过载：随着代码量增加，代码整体编译效率下降。

• 规模化：无法满足团队规模化高效开发。

• 系统开发、测试、部署的冲突和效率低下等问题

• 只能关注一套技术栈

• 应用扩展性比较差

• 海量用户高并发访问数量有限

单体适用场景：

　　架构设计的三大原则告诉我们，架构需要的是简单、适度、演化。

　　对于项目起步阶段，单体是最高效也是最节省成本的方式。因为初期阶段，由于人力，成本，业务熟悉程度，微服务技术积累等因素，如何过度设计可能工期和复杂度会急剧上升，造成交付困难，问题百出，从而错过了时间窗口。最合适，简单的方式还是单体优先，这是创业公司的特点决定的。当然设计面向微服务的单体架构也是一种聪明的方法，这遵守了系统演化的法则。

单体分层目的：

　　无论采取何种维度的架构分层，分层的最核心目的是保证各层之间的差异足够清晰，边界足够明显，为将来可能产生的变化提供最容易、最小化的修改。比如客户端要从安卓替换为IOS，底层无须任何改动，就像替换积木一样。又比如，设备需要接入新的设备或协议，其他层也不需要做任何变化，可以无缝平滑接入任何设备。

建议

　　如果前期在业务不十分清晰，求的是验证想法，证明产品思路是否可行性，并且业务量不大，仅限于省级范围，建议只要对当前架构稍加改良升级就可以了，这样改动量相对较小，且至少能支撑一定时间段的业务增长。

二、微服务架构

微服务的优势

　　支撑的业务更加庞大，可以支撑海量用户高并发和海量设备接入，支持分布式多机房，多区域部署，支持服务器无限扩容。支持私有云，公有云，混合云等部署方式。所以微服务是大多数互联网公司的首选。

微服务的代价

• 技术门槛高：微服务包括，服务描述，注册中心，服务框架，服务监控，服务追踪，服务治理等几大基本组件，以上每个组件缺一不可，每个组件展开又包括很多技术门槛，比如，容器技术，持续部署&