【关于分布式系统开发和微服务架构自我心得小记

一、一个完整项目为何要分布式开发？

完整项目业务实现是相当庞大，程序员在修改一个业务程序的的代码时，可能会影响整个项目的启动和部署，项目代码一个地方修改会产生很多问题，不利于程序的开发，同时项目的启动和部署是非常耗时，更不利于程序的运行。所以把一个项目拆成若各小项目块，单独修改，就能方便开发，在各个小板块之间，是通过网络来联系。一个单体应用拆分成多个服务，每个服务有自己独立的数据库。单个服务的复杂度降低。这就是微服务架构项目。

二、微服务架构是什么？

理论：微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务，我们仅做最低限度的集中管理。

分布式系统和微服务架构的关系。

微服务架构 是 分布式系统，分布式系统不一定是微服务架构；

比如 redis的中心化集群是分布是系统，但不是微服务；

应用系统当中，这两种的集群模式都有出现；

三、理解微服务中的分布式

怎样理解微服务中的分布式？举个招聘时某同学来面试的例子。A 同学说，目前所在公司在做从单应用到微服务架构迁移，已经差不多完成了。提到微服务感觉就有话题聊了，于是便问“是否可以简单描述下服务拆分后的部署结构、底层存储的拆分、迁移方案？”。于是 A 同学说，只是做了代码工程结构的拆分，还是原来的部署方式，数据库还是那个库，所有的微服务都用一个库，分布式事务处理方式是“避免”，尽量都同步调用……于是我就跟这位同学友好地微笑说再见了。

微服务的分布式不仅仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该互相独立，并且也不是所有的微服务都需要持久化的存储服务。一个“手机验证码”微服务可能底层存储只用一个 Redis；一个“营销活动搭建页面”微服务可能底层存储只需要一个 MongoDB。

微服务中的分布式场景除了服务本身需要有服务发现、负载均衡，微服务依赖的底层存储也会有分布式的场景：为了高可用性和性能需要处理数据库的复制、分区，并且在存储的分库情况下，微服务需要能保证分布式事务的一致性。

 微服务优缺点

优点
单一职责原则；
每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求