微服务能力层_微服务的七大原则

软件开发的三层架构模型(UI表示层、BLL业务逻辑层、DAL数据访问层)：

软件开发的三层架构

UI表示层：通常理解为用于和用户交互的视图层；

BLL业务逻辑层：用户提交请求，经过业务逻辑层处理后，对用户请求作出响应；

DAL数据访问层：主要用于操作数据库。

这种架构适用于用户业务不复杂、访问量较小的时候，甚至可以将应用服务、数据库、文件服务器部署在一台服务器上。但随着用户业务场景变得越来越复杂，单体架构的局限性就很快暴露出来了，主要体现在如下几方面：

随着业务越来越复杂，单体应用代码量急剧膨胀，最终导致代码可读性、可维护行和可扩展性得不到保证；

随着用户访问量增加，单体应用的并发能力有限；

随着系统代码量的剧增，当修改应用程序或者新增需求时，测试难度成指数级增长；

部署效率低下；

技术选型单一。

SOA架构(Service Oriented Architecture)

SOA架构

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML(标准通用标记语言的子集)/Web Service技术之后的自然延伸，SOA架构中有两个主要角色：服务提供者(Provider)和服务使用者(Consumer)。

其主要优点有：

把模块(即服务)拆分，使用接口通信，降低模块之间的耦合度；

把项目拆分成若干个子项目，不同的团队负责不同的子项目；

增加功能时只需要再增加一个子项目，调用其它系统的接口就可以；

可以灵活的进行分布式部署。

主要缺点：

和单体架构相比，增加了系统复杂度，系统整体性能有较大影响;

多服务数据通信协议之间转换过程复杂，容易造成ESB(Enterprise Service Bus)性能瓶颈。

微服务架构(MicroServices)

微服务架构

随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。

微服务的概念是Martin Flower在2014年写的一篇论文《MicroServices》中提出来的，在某种程度上是面向服务的架构SOA继续发展的下一步，微服务就是一些协同工作的小而自治的服务(进程)，很小、专注于做好一件事，具有自治性，其主要特点是：

与组织结构相匹配：每个服务可按照业务、团队划分，使小的团队在小的代码库上高效工作；

可组合性：易于重用已有功能；

技术异构性：可以使用不同语言开发，使用不同的数据存储技术，服务之间通过轻量级API调用；

简化部署：每个服务可独立部署，服务之间互相不影响，管理自动化；

弹性扩展：可针对用户访问流量大的服务单独扩展，从而能够节约资源；

对可替代性的优化：微服务中的多个服务大小相似，重写或移除一个或者多个服务的阻碍会很小。

主要挑战：

微服务粒度大小难以划分，需要设计人员对业务有很好的掌握；

分布式复杂性，主要体现在分布式事务、网络延迟、系统容错等问题解决难度较大；

微服务之间通信成本较高，对微服务之间网络稳定性、通信速度要求较高；

由于微服务数量较大，运维人员运维、部署有较大的挑战。

微服务的七大原则

1、围绕业务概念建模

经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好地反映业务流程的变化。使用限界上下文来定义可能的领域边界。

2、接受自动化文化

微服务引入了很多复杂性，其中的关键部分是，我们不得不管理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期花费一定的成本，构建支持微服务的工具是很有意义的，比如：自动化测试，调用一个统一的命令行，以相同的方式把系统部署到各个环境；使用环境定义来帮助你明确不同环境间的差异，同时保持使用统一的方式进行部署；创建自定义镜像来加快部署，创建全自动化不可变服务器。

3、隐藏内部实现细节

为了使一个服务独立于其他服务，最大化独立演化的能力，隐藏实现细节至关重要。隐藏服务的数据库，以避免陷入数据库耦合；使用数据泵(data pump)或事件数据泵(event data pump),将跨多个服务的数据整合到一起，以实现报表功能。

4、让一切都去中心化

为了最大化微服务能带来的自治性，我们需要持续寻找机会，给拥有服务的团队委派决策和控制权。

在这个旅程中，确保团队保持对服务的所有权是重要的一步，理想情况下，甚至可以让团队自己决定什么时候让那些更改上线。使用内部开源模式，确保人们可以更改其他团队拥有的服务，不过请注意，实现这种模式需要很多的工作量。

像企业服务总线或服务编配系统这样的方案，会导致业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来代替编排或哑中间件，使用智能终端点(smart endpoint)确保相关的逻辑和数据，在服务限界内能保持服务的内聚性。

5、可独立部署

我们应当始终努力确保微服务可以独立部署。我们也应该同时提供新旧两个版本，允许消费者慢慢迁移到新版本。当使用基于RPC的集成时，避免使用像Java RMI提供的那种使用生成的桩代码，紧密绑定客户端/服务器的技术。

通过采用单服务单主机模式，可以减少部署一个服务引发的副作用，比如影响另一个完全不相干的服务。请考虑使用蓝/绿部署或金丝雀部署技术，区分部署和发布，降低发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕获它们。

请记住，你可以更改单个服务，然后把它部署到生产环境，无需联动地部署其他任何服务，这应该是常态，而不是例外。你的消费者应该自己决定何时更新，你需要适应他们。

6、隔离失败

微服务架构比单块架构更具弹性，前提是我们了解系统的故障模式，并做出相应的计划。

如果我们心中持有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确的路上。请确保正确设置你的超时，了解何时及如何使用舱壁和断路器，来限制故障组件的连带影响。如果系统只有一部分行为不正常，要了解其对用户的影响。知道网络分区可能意味着什么，以及在特定情况下牺牲可用性或一致性是否是正确的决定。

7、高度可观察

我们不能依靠观察单一服务实例，或一台服务器的行为，来看系统是否运行正常。相反，我们需要从整体上看待正在发生的事情。通过注入合成事务到你的系统，模拟真实用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样当你遇到问题时，就可以深入的解析原因。而当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识可以帮助你跟踪系统间的调用。