单体架构与微服务架构

产品初期优先选择单体架构。面对一个新的领域，对业务的理解很难在开始阶段就比较清晰，往往是经过一段时间之后，才能逐步弄清楚。很多时候，从一个已有的单体架构中逐步划分服务，要比一开始就构建微服务简单得多。另外，在资源受限的情况下，采用微服务架构风险较大，很多优势无法体现，性能上的劣势反而会比较明显。
单体、组件化、微服务架构成本趋势，当业务复杂度达到一定程度后，微服务架构消耗的成本才会体现优势，并不是所有的场景都适合采用微服务架构，服务的划分应逐步进行，持续演进。产品初期业务复杂度不高的时候，应该尽量采用单体架构。

微服务是系统架构设计风格， 它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RSTful API进行通信协作。
微服务架构特点

被拆分的每一个小型服务都围绕着系统中的某一项或某一些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、 业务开发、自动化测试案例以及独立部署机制。

由于有了轻量级的通信协作基础， 微服务就可以使用不同的语言来编写。

单体服务架构

单体服务架构的特点

各个功能模块写在同一个项目中，部署到一台机器上
一个项目由多个开发人员甚至多个团队一起进行开发维护
缺点：
不灵活：改一个功能需要对整个服务进行重新编译打包部署，某个功能达到瓶颈需要整个服务进行扩容
不稳定：某个模块的故障可能影响整个服务
迭代低效：一个庞大的单体服务往往是由多个开发人员甚至团队合作管理的，这回大大提高需求推进中的沟通成本

微服务架构

传统的单体架构难以适应互联网快速迭代、大规模、高并发等需求，微服务架构也就应运而生，微服务架构一般有以下特点

将服务拆分成多个单一职责的小的服务，进行单独部署，服务之间通过网络进行通信
每个服务应该有自己单独的管理团队，高度自治
  微服务架构能有效解决单体架构遇到的一些问题

灵活扩展：可以根据各个服务的瓶颈灵活水平伸缩
稳定：服务各自有自己单独的职责，服务之间松耦合，避免因一个模块的问题导致服务崩溃
高效迭代： 各个服务独立开发、迭代，高度自治，提升效率

缺点：

• 运维层面上，运维需要维护的服务更多了
• 问题难定位，单体项目日志集中在一起，出现问题好定位，而微服务通过日志去定位问题比较困难
• 微服务的雪崩问题，由于网络的不稳定性，不可能保证每个服务100%可用，如果某个服务发生问题，可能会导致依赖服务阻塞，最终引发雪崩效应
• 分布式的复杂性，由于服务都独立部署，事物问题、网络延迟等问题会增大业务的复杂性

缺点的解决方案：

• 运维层面上可以写自启动脚本
• 定位问题方面可以将日志文件写到一起
• 雪崩问题可以添加服务可用性监控
• 分布式复杂性问题，可以使用分布式事务解决事物问题