微服务架构核心是传统单体应用大拆小，同时拆分为小的微服务后相互之间以轻量的API接口进行通信。而这个拆分本身又分了多个方面，开发团队的拆分，代码层的拆分，可独立构建打包，数据库的拆分。
在拆分后为了更加敏捷开发和集成，引入了DevOps和容器云技术。同时考虑和SOA，中台思想的融合，考虑到API接口的复用性，进一步对单个微服务也进行了前后端分离开发。
从单微服务的概念来说，微服务不是指具体的Http API接口服务，而是指拆分后的微服务模块，因此微服务可以理解为：拆分后DB+微服务模块+API接口提供。
微服务架构思想符合当前复杂应用系统分而治之的思想，这个和微服务出来前的组件化开发思路是一致的，只是微服务思想出来后对于拆分的微服务更加高度解耦和独立自治。
系统复杂性本身也分为了功能和非功能两个层面。
比如一个传统的大业务系统，类似ERP，合同管理等，业务系统足够复杂，需要考虑进行分为治之方便后期管理和扩展。其次是非功能性需求导 致的复杂性，比如一个业务系统功能并不多，但是文件存储和获取量巨大，那么文件服务就需要单独拆分为微服务。
微服务拆分后虽然降低了单个微服务开发实现的难度，但是增加了集成的难度，拆分的越细集成越复杂。因此如果本身不具备上面谈到的复杂性需求，一个业务系统没有必要进行微服务架构拆分和改造。
PS：转自人月神话博客。
