本文目录
什么是微服务架构
微服务是指开发一个单个 小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上.
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构.也就是说,如果每个服务都要同时修改,那么它们就不是微服务,因为它们紧耦合在一起;如果你需要掌握一个服务太多的上下文场景使用条件,那么它就是一个有上下文边界的服务,这个定义来自DDD领域驱动设计.
微服务有哪些设计原则
微服务应用4个设计原则：
我们总结了四个原则推荐给大家：
AKF拆分原则
前后端分离
无状态服务
Restful通信风格
前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI\ 移动App等访问。
无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案HTTPS可用。
JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
1.AKF拆分原则
AKF扩展立方体(参考《The Art of Scalability》)，是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。
Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。
场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。-微服务架构设计模式
2.前后端分离
前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：-微服务
3.无状态服务
对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。-微服务架构设计模式
4.Restful通信风格
作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的Restful 通信风格 ，因为他有很多好处：
当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。
主流的微服务架构有哪些
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
中文名
微服务架构
外文名
microservice
服务平台
Imixs-Workflow
属性
Seneca是构建微服务框架的工具
现状
当下最新的热门话题
快速
导航
现状 特点 服务平台 工具开发
概念
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
现状
微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展，理论上是这样。
-微服务
微服务开发中的数据架构应该怎样设计
前言
微服务是当前非常流行的技术框架，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点，本文包括下面若干内容。-微服务架构设计模式
微服务技术框架中的多层数据架构设计
数据架构设计中的要点
要点1：数据易用性
要点2：主、副数据及数据解耦
要点3：分库分表
要点4：多源数据适配
要点5：多源数据缓存
要点6：数据集市
为了容易理解，本文用一个简化的销售模型来阐述，如下图。图1显示了客户、卖家、商品、定价、订单的关系（这里省略支付、物流等其他元素）。
图1 销售模型
在这个销售模型中，卖家提供商品、制定价格，客户选择产品购买、形成销售订单。根据微服务的理念设计，可以划分为客户服务、卖家服务、商品服务、定价服务、订单服务，以及公共服务（比如认证、权限、通知等），如图2所示。-微服务
图2 微服务功能
微服务架构中的多层数据架构设计
分布式架构一般把系统分为 Saas（Software-as-a-Service）、Paas（Platform-as-a-Service）、Iaas（Infrastructure as a Service ）三层。其中 Saas 层负责对外部提供业务服务，Paas 层提供基础应用平台，Iaas 层提供基础设施。微服务垂直嵌入这三层服务之中，相互独立。因此数据架构设计时需要考虑三层服务对数据的关注点，又要考虑微服务的独立性。-微服务架构设计模式
数据架构的分层设计
图3 微服务技术框架
如图3所示，Iaas 层提供程序运行的物理基础环境（这边涉及很多硬件·网络内容，在本文中省略）。Pass 层细分为三层，基础服务层，主要负责数据存储处理；事务框架层，主要负责微服务的注册·调度管理、分布式事务处理；应用服务层、主要实现各个微服务的 API，供其它微服务直接调用以及 Saas 层的服务调用。Saas 服务就是公开对外提供的业务服务。-微服务
数据架构自下向上相应的分为 Raw Data 层、Logic Data（inner）层和 Logic Data（outer）层（Iaas 中主要以基础硬件环境为主，在本文中省略）。Raw Data 层是基于数据库、文件或者其他形式数据内容。Logic Data（inner）层是微服务 API 使用的逻辑数据，比如客户数据、订单数据等等。Logic Data（outer）层是对外服务提供数据，比如客户订单数据。因此，我们的数据架构的分层结果如图4所示。-微服务架构设计模式
图4 数据分层架构
除此之外，很多情报会以画面或报表的形式展现出来。因此在 Logic Data(outer) 之上，可以构建 Information Block（常用的信息块）、通过 View type（显示模式）的设定后，最终 View 展现出来。-微服务
如图4所示，越靠近对外服务层，客户对设计者的影响度越大，越需要从使用性、易用性、适用性等考虑。反之，越远离对外服务层，设计上更关心数据的存储。
数据三层架构的好处是实现数据从系统实现到业务实现的逐层过渡，实现业务数据和系统数据间的松耦合。同时实现业务的灵活扩展和系统的灵活扩展。
数据架构设计中的要点
上面讲述了数据架构的分层设计，下面讲述数据架构设计中的要点。
要点1：数据易用性
数据无论用什么方式实现，其最终目的都是为业务（或者是客户）使用的。因此，在对外提供服务的时候，数据的易用性非常关键。
图5 数据易用性
如图5所示，客户信息在 Logic Data（inner） 层中为了数据的柔软性和非冗余，把人员信息拆成若干子表来存储。比如，人员地址表可以无限多的存储客户地址信息。这样的好处在于每次人员地址更新时，不用直接更新人员地址，而是生成一个新的地址数据，原有的地址信息作为历史数据得到保存，易于数据快速恢复和历史信息追踪。但在 Logic Data（outer）层提供外部数据的时候，首先考虑的是一次性能提供足够用的信息（毕竟查询的操作大大高于修改的操作），减少业务场景中不需要的信息。比如对一般客户只提供三个常用地址的时候，数据设计中地址1、地址2和地址3放在一张表中。-微服务架构设计模式
要点2：主、副数据及数据解耦
每个微服务 API 的数据完全独立是不太现实的，比如订单中需要有商品、客户（包括收货者）、卖家以及价格等数据。如果这些数据都在订单服务 API 中管理，那么客户情报的变更、价格调整等信息都要同步给订单 API 中数据，数据的耦合度就会变得非常高。在数据设计的时候，需要考虑降低数据间的相互依赖性。因此，首先需要确定每个微服务 API 的主数据和副数据。主数据指微服务 API 的核心数据，这种数据的增删改主要集中在某个微服务 API 中，比如订单服务 API 中的订单数据。副数据指参照或者映射其他微服务 API 的数据，比如订单服务 API 中的商品数据、价格数据等。其次，为了降低数据之间的耦合度，用数据关联表来表征数据间的关系。如果想去掉数据间的关联关系，直接去掉关联表即可，对数据本身的没有任何影响。具体如图6所示。-微服务
图6 主、副数据及数据解耦
要点3：分库分表
随着业务数据量不断增加，单一数据库或单一数据表中会积累大量的数据，比如订单数据，随着时间推移和客户数量的增加，产生的订单数据也会越来越多。当数据累积到一定程度后，数据操作的性能会大幅下降，也就是我们常说的数据库“带不动了”。所以，在数据架构设计阶段就应该考虑数据的分库分表。-微服务架构设计模式
如图7所示，分库，即我们把订单数据分为当前数据应用库、历史数据库、历史归档数据库。当前数据应用库用来支持新订单的生成以及执行中订单的增删改查。历史数据库（这里举例分为最近3个月和最近1年）当客户想看过往订单的时候才使用。历史归档数据（按年间归档）原则上不直接对客户公开，用于备查、统计分析。对于当前数据应用库，可以继续再分库，按客户号范围来分库。这样每个数据库的大小都能得到有效控制。分表，即把一条信息分别存储在两张或多张表中。比如把订单信息按基本信息和详细信息分表，就可以适用于订单的基本信息查询和订单详细信息查询。总之，分库分表的核心就是控制单一数据库的负荷（数据量和数据信息量），通过多表多库来应对业务数据量的增长。-微服务
图7 分表分库
要点4：多源数据适配
传统的关系型数据库之外，有多种多样的数据源，比如图像、声音、视频等多媒体数据文件或数据流，CSV、TXT、Doc、Excle、PDF、XML 等各种异构数。这些数据都需要做相应的处理，转换成可管理的数据信息。因此在数据架构设计的时候，需要给不同性质的数据源配置相对应的读写适配器，同时也需要有统一调度的地方，如图8所示。-微服务架构设计模式
图8 多源数据适配
要点5：多源数据缓存
数据处理的性能除了处理逻辑的复杂度以外，还有很大一部分是目标数据的操作时长（含对硬件磁盘设备的读写以及网络的传输）。网络速度特别是光纤的使用后已经大幅度提高，但机器磁盘的读写效率并没有显著提高，因此减少磁盘读写是提高效率的一个重要途径。数据缓存就是把常用的数据（不会经常更改的数据）、最近使用数据放到内存中。这样就可以大幅降低系统对硬件磁盘设备的操作开销，提高整个数据系统的性能，如图9所示。-微服务
图9 数据缓存
要点6：数据集市
数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候，就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据，通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后，为业务提供可用的、稳定的数据源。例如，对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析，就要用数据集市的概念，如图10所示。-微服务架构设计模式
图10 数据集市
数据承载着信息，好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。本文只是总结一些在实际工程中的体会，供大家分享。如果有不足之处、也请大家补充、赐教。
（此文转载至GitChat技术杂谈）
微服务架构的优缺点
微服务在近几年大火，它具备了灵活部署、可扩展、技术异构等优点，但同时也带来了开发、运维的复杂性。是否要采用微服务架构需要根据系统的特点，结合企业的组织架构、团队能力等多个方面进行综合的判断，而不是为了微服务而微服务。例如基于微服务架构的MK-PaaS平台，通过将传统流程服务、组织服务、门户服务、消息服务、集成服务、生态组织、主数据等能力中台化；并提供统一集成&开发能力，整合生态服务能力。帮助大、中型组织高效构建内、外协作一体化的数字化平台，提高生态型组织的效率，提升业务敏捷度，夯实产业互联网&商业模式创新基座，赋能数字化转型升级，敏捷应对业务需求变化。
-微服务
什么是微服务架构啊
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。-微服务架构设计模式
微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。-微服务
微服务架构的优点：
每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
微服务架构的缺点：
微服务架构可能带来过多的操作。
需要DevOps技巧 (
