微服务是开发可扩展云原生系统的强大工具,但为了避免严重的系统灾难,需要认真设计才能成功。微服务并不是解决所有架构问题的普适方案,过度的设计、不当的应用和错误的理解容易导致系统灾难。选择正确的应用方向对于成功开发微服务极其重要,而权衡利弊做出正确的设计决策同样重要。下面详细讨论设计微服务时需要考虑的一系列因素:
一、确定微服务的边界。
微服务设计最常见的一个问题就是服务的大小问题。设计微服务边界,最可行的办法就是通过一系列方案来模拟现有的业务场景,某些特定的业务可能会同时匹配多个要素条件,此时就需要架构师权衡利弊。
1,工具类函数,加密解密引擎或者通知引擎。
2,恰当的子域,比如半数请求是搜索的情况,可以考虑将搜索功能独立出来
3,事务一致性,比如预定酒店需要保持事务一致性,而搜索不需要,就可以考虑将其独立出来
4,团队分工,比如搜索服务需要用到推荐算法机器学习等专家系统,可以由独立的专家团队开发成一个独立的微服务
5,单一责任,理论上单一责任可以用到方法、类或者服务上。但在微服务的上下文中,单一责任不一定需要映射到某个服务上,更可行的办法是将单一责任理解为单一业务功能或者单一技术能力。比如酒店客户信息的读取和写入操作可以使用命令查询职责分离CQRS方式来实现两个微服务
6,创新和速度,满足业务功能和快速交付,如何最快实现并产生价值是微服务最为重要的
7,耦合和内聚,设计微服务时,应尽量避免服务间过多的频繁通信和循环同步依赖
8,把微服务视为产品,综合考量服务的目标群体、部署灵活性和可复用行
二、设计微服务的通信方式
1,同步和异步的方式如何取舍,从原则上看,异步才是最适合开发微服务系统的,但异步机制会让系统设计极其复杂。最好的做法是开始时先用同步请求响应的方式,之后在异步通信有需要时再进行重构,也可以使用响应式编程框架,来必满用户的异步请求系统复杂化
三、服务编排
1,在一个微服务内部组装或调用多个微服务接口的做法是可以考虑的,但要因此新建一个微服务可能会创建很多细粒度、非自治跟业务不对应的组合微服务。可以考虑将上游服务数据向外推送的方式,下游微服务通过监听缓存或者消息中间件来获取需要的数据。
四、每个虚拟机应该运行多少个微服务
1,最好先在一台虚拟机部署关联的多个微服务
五、规则引擎和工作流引擎
1,如果规则或者工作流比较简单,数量也不多,尽量服务内编写规则或工作流,反之应该使用独立的引擎
六、数据库
1,原则上每个微服务应该都使用独立的数据库,某些简单场景就几张表,可以只使用一个数据库。 比如客户主数据和客户详情
七、确定事务边界
1,尽量避免分布式事务
八、服务的版本化
1,对REST服务进行版本化有三种方式:URL包含版本号,Http请求头设置版本号和自定义头部版本号信息
九、跨域设计
1,一种做法是在REST接口添加@CrossOrign ,另外一种做法是用API网关作为客户端唯一信任的域名
十、日志存放
1,由于各个微服务有可能独立部署,其日志文件也分散在各处,最好是将日志汇总到一处进行存储并提供查询分析功能。ELK和Graylog都是可以考虑的解决方案
标签:10,需要,服务,异步,设计,考虑,单一,要素 From: https://www.cnblogs.com/chuyuan/p/18407181