免费源码资源源码站,成都app开发多少钱,台州市建设规划局网站,j2ee大型网站开发框架转载自 为什么选择微服务架构#xff1f;如何取舍#xff1f;
微服务是什么
微服务是一种架构风格#xff0c;一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署#xff0c;各个微服务之间是松耦合的。每个微服务仅关注于完成…转载自 为什么选择微服务架构如何取舍
微服务是什么
微服务是一种架构风格一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”。 尽管“微服务”这种架构风格没有精确的定义但其具有一些共同的特性如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。
微服务架构的思考是从与整体应用对比而产生的。
其中对应用组件封装的方式是整体架构与微服务架构的主要差异微服务架构将相关联的业务逻辑及数据放在一起形成独立的边界其目的是能在不影响其他应用组件(微服务)的情况下更快地交付并推出市场。 为什么需要微服务架构
传统IT架构的问题
“微服务”架构是近期软件应用领域非常热门的概念。让我们先来看看传统IT架构面临的一些问题
使用传统的整体式架构(Monolithic Architecture)应用开发系统如CRM、ERP等大型应用随着新需求的不断增加企业更新和修复大型整体式应用变得越来越困难
随着移动互联网的发展企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备这要求企业能实现应用功能的快速上线
许多企业在SOA投资中得到的回报有限SOA可以通过标准化服务接口实现能力的重用但对于快速变化的需求受到整体式应用的限制有时候显得力不从心
新应用的出现
随着应用云化的日益普及生于云端的应用具有与传统IT不同的技术基因和开发运维模式。
此外从技术方面看云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟
互联网/内联网/网络更加成熟
轻量级运行时技术的出现(node.js, WAS Liberty等)
新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)
新的轻量级协议(RESTful API接口, 轻量级消息机制)
简化的基础设施操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等
服务平台化(PaaS) 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务
新的可替代数据持久化模型如NoSQL, MapReduce, BASE, CQRS等
标准化代码管理如Github等。
这一切都催生了新的架构设计风格 – 微服务架构的出现。
微服务通用特性
根据MartinFowler的分析微服务架构有以下的一些通用特性但并非所有微服务架构应用都必须具备所有这些特性
1.组件化
通过服务实现应用的组件化(Componentizationvia Services)微服务架构中将组件定义为可被独立替换和升级的软件单元在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
2.跨功能
围绕业务能力组织服务(Organizedaround Business Capabilities)微服务架构采取以业务能力为出发点组织服务的策略因此微服务团队的组织结构必须是跨功能的如既管应用也管数据库、强搭配的DevOps开发运维一体化团队通常这些团队不会太大如亚马逊的“Two pizzateam”- 不超过12人。 3.产品模式
产品而非项目模式(Productsnot Projects)传统的应用模式是一个团队以项目模式开发完整的应用开发完成后就交付给运维团队负责维护微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期倡导“谁开发谁运营”的开发运维一体化方法。
4.扁平化
智能端点与管道扁平化(Smartendpoints and dumb pipes)微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
5.去中心化
去中心化治理
“去中心化”治理(DecentralizedGovernance)整体式应用往往倾向于采用单一技术平台微服务架构则鼓励使用合适的工具完成各自的任务每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
去中心化数据管理
“去中心化”数据管理(DecentralizedData Management)微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法让每个微服务管理其自有数据库并允许不同微服务采用不同的数据持久化技术。
基础设施自动化(InfrastructureAutomation)云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
6.故障处理设计
故障处理设计(Designfor failure)微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
7.演进式设计
演进式的设计(EvolutionaryDesign)微服务应用更注重快速更新因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用但逐渐朝微应用架构方向演进整体式应用仍是核心但新功能将使用应用所提供的API构建。再如在某微服务应用中可替代性模块化设计的基本原则在实施后发现某两个微服务经常必须同时更新则这很可能意味着应将其合并为一个微服务。 微服务常见误解
一些比较概念的澄清
在同一范畴内比较才有意义
微服务架构 vs. SOA– 两者都是架构风格范畴但其关注领域与涉及范围不同。SOA更关注企业规模范围微服务架构则更关注应用规模范围。
微服务组件 vs. 服务组件 – 两者都是描述业务功能的具体实现其区别在于粒度不同此外还有在可管理性、灵活性上的差异。
概念混淆的不恰当比较
微服务 vs. SOA – 不恰当的比较。微服务是组件范畴而SOA是一种架构设计风格。因此应该比较的是微服务架构与SOA。
微服务 vs. API – 不恰当的比较。 API是接口是业务功能暴露的一种机制。微服务架构是用于实施业务功能的组件架构。因此直接比较它们是没有意义的。
微服务 vs. 服务– 不恰当的比较。“服务”在不同的场景下有不同的含义需要进一步澄清其描述的语境是指服务实施、服务暴露、服务定义还是其
他微服务亦是如此需要有特定语境才可判断比较是否有意义。
收益应用
哪些应用会从微服务收益
记录型系统(System of Record)将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。
交互型系统(System of Engagement)也将受益于微服务方法例如渠道应用可以应用“后端服务前端”的模式实现。
分析型系统(System of Insight)则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。 微服务架构的优点
1.每个服务都比较简单只关注于一个业务功能。
2.微服务架构方式是松耦合的可以提供更高的灵活性。
3.微服务可通过最佳及最合适的不同的编程语言与工具进行开发能够做到有的放矢地解决针对性问题。
4.每个微服务可由不同团队独立开发互不影响加快推出市场的速度。
5.微服务架构是持续交付(CD)的巨大推动力允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。 微服务架构的缺点
微服务的一些想法在实践上是好的但当整体实现时也会呈现出其复杂性。
缺点一
运维开销及成本增加整体应用可能只需部署至一小片应用服务区集群而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成可能需要40~60个进程。
缺点二
必须有坚实的DevOps开发运维一体化技能开发人员需要熟知运维与投产环境开发人员也需要掌握必要的数据存储技术如NoSQL具有较强DevOps技能的人员比较稀缺会带来招聘人才方面的挑战。
隐式接口及接口匹配问题把系统分为多个协作组件后会产生新的接口这意味着简单的交叉变化可能需要改变许多组件并需协调一起发布。在实际环境中一个新品发布可能被迫同时发布大量服务由于集成点的大量增加微服务架构会有更高的发布风险。
缺点三
代码重复某些底层功能需要被多个服务所用为了避免将“同步耦合引入到系统中”有时需要向不同服务添加一些代码这就会导致代码重复。
分布式系统的复杂性作为一种分布式系统微服务引入了复杂性和其他若干问题例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等开发人员需要考虑以上的分布式系统问题。
缺点四
异步机制微服务往往使用异步编程、消息与并行机制如果应用存在跨微服务的事务性处理其实现机制会变得复杂化。
缺点五
可测性的挑战在动态环境下服务间的交互会产生非常微妙的行为难以可视化及全面测试。经典微服务往往不太重视测试更多的是通过监控发现生产环境的异常进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。 关于微服务架构的取舍
在合适的项目合适的团队采用微服务架构收益会大于成本。
微服务架构有很多吸引人的地方但在拥抱微服务之前也需要认清它所带来的挑战。
需要避免为了“微服务”而“微服务”。
微服务架构引入策略 – 对传统企业而言开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用逐步探索及积累微服务架构经验而非全盘实施微服务架构。
