关于微服务的一些思考

什么是微服务架构？

将一个原来独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程支行，服务之间通过基于HTTP的RESTful API进行通讯协作。

 

与单体系统的区别

单体系统：

（1）开发、测试、部署都在一个应用

（2）后期随着模块增多，应用会变得复杂臃肿

（3）各模块硬件资源进程内共享，互相影响，维护成本大

微服务：

（1）业务拆分为不同进程，可独立部署和扩展

（2）各服务间有稳固边界，版本更新不会影响其它服务

（3）维护专注，可以准确地评估服务性能容量

 

微服务的实施

• 服务组件化

组件，是一个可以独立更换和升级的单元。在微服务架构中，服务可以是一种进程的组件，可以独立开发、部署。

 

• 按业务组织团队

按业务线划分团队，使得一个团队相关业务线的一个或多个微服务。这样，一方面可以有效减少服务内部修改所产生的内耗，另一方面团队边界可以变更更为清晰。

 

• 做产品的态度

每个小团队都应以做产品的方式，对其产品的整个生命周期负责，而不是以做项目的模式。

 

• 智能端点与哑管道

单体应用中，组件间直接通过函数调用方式进行交互协作，然而在微服务架构中，组件间的通信模式发生了改变。

通常服务有两种调方式：

（1）同步方式：使用HTTP RESTful API或其它轻量级的RPC协议

（2）异步方式：通过在消息总线上传递消息，服务提取消费，运作业务

 

• 去中心化治理

通过采用轻量级的契约定义接口，各服务可以针对不同的业务特点选择不同的技术平台。

 

• 去中心化管理数据

每个服务来管理自有的数据库，这就是数据管理的去中心化

 

• 基础设施自动化

如自动化测试、自动部署等

 

• 容错设计

需要能快速检测出故障源并尽可能自动恢复服务是必须被设计和考虑的。

 

• 演进式设计

通过以上几个特征，初期实施微服务的成本不小。一开始业务不大，可考虑单体应用设计快速上线。业务壮大后，可以再考虑重构拆分，向分布式微服务架构演进。

 

微服务存在的问题

（1）服务多，机器会多，运维成本增加，需要更多运维自动工具

（2）分布式的复杂性，设计时需要考虑的重要因素：网络延迟、分布式事务、异步消息