微服务的概念、优缺点和一些使用过的思考

什么是微服务？

最早没有参加过工作的时候，不太理解微服务是什么。毕竟之前自己做的项目都比较小，还没有到“单体地狱”那么麻烦的程度。后面参加工作，经历了40多后端服务搭建成的一个产品线，突然就理解微服务的概念了。

服务本身是一个小巧但是功能齐全的应用程序，它实现的是一组相关功能，比如订单管理，身份识别，用户中心等等。
这些服务可以根据需求进行用例部署层面的实例扩展，或者是使用路由将请求发给不同namespace的服务。

微服务的理念就是 将服务拆分为一组服务的架构风格

微服务的特点

1. 服务直接都是松耦合的关系 仅仅通过API进程调用相连
2. 每个服务都有自己的私有数据库和数据模型
3. 运行时服务是相互独立的

微服务架构的好处

• 使大型复杂的应用程序都可以持续交付和持续部署
• 每个服务都相对较小并且好维护
• 服务可以独立部署
• 服务可以独立扩展
• 微服务架构可以实现团队自治（两个披萨原则）
• 更容易实验和采用新的技术
• 更好的容错性

对于单体服务而言，持续交付是比较困难的事情，但是对于微服务来说，当个服务的部署不影响其他服务的运行。使用devops也可以让部署的过程减少错误和故障。

微服务架构持续交付和持续部署的方式

1. 可测试性：自动化测试 ， 因为微服务的服务程序和接口内容都比较小，所以自动化测试的case非常好写，应用程序的bug也会更少。
2. 可部署性：服务可以独立与其他的服务进行部署，不需要与其他服务的开发人员进行协调。
3. 可以使开发团队松散耦合： 每个团队更专注于一块业务，并且可以让一到两人负责一个微服务，减少沟通的成本。 每个服务有自己的人员安排和代码仓库，并且部署走的是自己的流水线（jenkins），小巧简单更容易维护，出了问题能够更明确的找到相应负责人排查问题。

持续交付的一些优点：

• 产品的研发速度加快
• 程序的鲁棒性更好，能够达到客户的预期
• 员工可以更专注于自己服务的维护和开发，精力更加几种，有助于研发团队和测试团队提升工作效率
• 将单独的服务进行拆分，可以在未来做新服务的时候，提供相同的能力，这部分的服务可以复用，节省成本，所以很多公司的中台都是用微服务的开发模式。

微服务的一些弊端

1. 服务的拆分和定义较为困难
2. 分布式系统带来的各种复杂性，使得开发、测试和部署变得困难
3. 部署多个跨越服务的功能时需要谨慎的协调更多的开发团队
4. 开发者需要思考在什么阶段使用微服务架构

服务的拆分也是一门艺术，如果不能清晰地划分各个功能，就会导致构建出一个分布式的单体应用，这样会导致两种服务的缺点都会集中在一起。

分布式可以在扩展和维护上面带来便利，同时由于将不同的业务进行拆分也会导致产生一些分布式特有的复杂情况。

1. 只能通过API对某些服务的数据进行访问
2. 必须使用saga来维持服务数据之间的一致性
3. IDE都是为了单体模式设计的，无法致辞分布式应用所使用的特定功能，与此同时自动化测试包含多个服务的程序也是比较麻烦的。比如在正常的测试当中某一个接口依赖了其他的接口，在测试的时候虽然可以使用mockery来模拟该接口的返回内容，但是在实际的运行中还是会有返回超出预期的内容，所以要求在编写相应内容的时候需要对使用的其他服务的一些接口有相应的了解，这点也增加了开发测试的复杂性。
4. 运维难度，微服务的项目的交付必须依赖于完整高效的基础设施建设，快速部署的前提离不开运维同学的支持，同时多个容器的管理也增加了运维的难度。

跨多服务部署的人员协调问题，服务之间总是相互依赖的，因此在产品发布之前，必须和相应的团队协商服务的开发时间。

什么时候使用微服务架构是一个难题

对于一个企业的发展来说，在什么时候选择进行技术架构的变革是一个难题。在程序的第一个版本时通常不会使用微服务的架构，因为精心设计的分布式需要很多组件支持，也需要公司提供运维支持，会拖慢开发的进度，对于初创公司时间就是金钱。
但是，随着用户需求的增加，单体的服务变得难以维护，重构和部署都变得困难，团队的整体速度被拖慢。转型为微服务架构，过程可能是痛苦的，但是可以走的更长远，没有完美的解决方案，但是只能逐步改善和优化。