单体式架构与微服务架构

一、单体式架构与微服务架构

1.单体式架构
将项目的所有源代码都放置于一个总项目中进行开发、管理、部署。其缺点如下：
1）项目迭代不灵活
对于互联网项目而言，软件提供商经常会根据用户的不同体验需求来调整项目功能，即更新迭代软件版本。而单体式架构把项目代码合归一处，迭代的版本越多代码就越多、越乱。在一个项目中去寻找修改指定模块的代码非常困难，而且容易影响已上线功能。
2）项目组职责、权限分不清
由于项目比较庞大，大多需要分布同的项目组进行开发，各项目组之间需要进行严格的代码保密和权限划分，以避免核心代码泄露和错改其他项目组的代码。而单体式架构则将所有项目的源码暴露给项目开发的所有成员，更容易引发风险。
3）项目并发设置不灵活
对于互联网项目而言，面对的用户是互联网上的所有用户，在开发过程中需要考虑项目在高并发下的处理能力。传统的单体式架构多采用集群方式横向扩展，也就是增加机器做负载均衡
2.微服务架构
微服务架构是将原来庞大的项目进行拆分，拆分后的每一个模块独立形成一个新的项目，服务之间可按照一定方式进行通信的架构。其优点如下：
1）项目复杂度降低
微服务架构将应用分解为多个服务的方法解决了复杂性的问题，在功能不变的情况下应用可被分解为多个可管理的服务，使每个项目的代码量大大减少且关注的业务更加专一。
2）团队界限明确
微服务架构使每个服务都由专门的开发团队来负责开发，不同的团队可以按自己所需选择不同的开发技术，团队之间只需定义好服务调用规则即可。
3）部署灵活
微服务架构可以使每个服务都能进行独立扩展，如订单模块访问量较大，可以将订单服务模块多部署几个到服务器上，不用像单体式架构服务，需要将整体项目一起部署。

二、微服务架构概念

1.调用方式
1）RPC
RPC即Remote Procedure Call（远程过程调用），通俗地讲，就是可以在一个项目中像调用本地服务一样去调用其他项目的服务。
2）REST
REST全称是Representational State Transfer，是一组架构约束条件和原则。可以理解为在Web请求中，将参数封装于URL内部，在微服务中项目之间可以采用RESTful风格的HTTP方式互相进行调用。
2.设计原则
1）围绕业务切分
在决定将项目分成多个子项目时，需要按照对应的业务进行划分，避免业务过多交叉，接口实现复杂。
2）单一职责
在服务设计上每一个服务的职责尽可能单一，这样可以保证服务的模块化协作，即多个服务互相搭配完成一个整体功能。
3）谁创建，谁负责
采用微服务架构的对项目进行拆分后出现了很多小项目，为减少沟通成本，一般由其开发团队对项目的开发、部署、维护进行负责。