微服务浅谈、WiredTigerVsMMAPv1

summary_2018/08 mongodb arch

1、日常工作

1.1、WiredTiger VS MMAPv1

1.2、微服务架构体系浅读

2、技术学习

2.1、WiredTiger VS MMAPv1

• WiredTiger 和 MMAPv1的一些主要区别
  

## 空间分配算法不同（write）
MMAPv1使用的是线性存储。为了使得同一个文档的数据在磁盘上也保持在相同的位置上, 我们需要解决 “当对文档进行更新时, 如果文档是无缝紧密排列的, 那么多出的空间就需要被放在磁盘的别处” 这一问题。MMAPv1是这样解决的:
在写入时, MMAPv1会为文档预分配一定的磁盘空间, 32KB, 64KB, ..., 2MB, 如果文档超过2MB, 则会自动向上fix到2MB的倍数。当然,文档大小不能超过16MB的限制。而预分配空间和文档实际占用的磁盘大小之间的差值, 会用Padding来补足。（3.0以前使用填充因子）
Tips：由于新引擎WiredTiger使用的是BTree存储, 不是线性存储, 所以压根不需要Padding。
## 并发级别
MMAPv1在3.0之前仅支持数据库级别，3.0之后，支持集合级别。
WiredTiger通过MVCC实现文档级别的并发控制，即文档级别锁。
## 压缩支持
WiredTiger的数据是经过压缩的, 在MMAPv1中是没有经过压缩的。 默认情况下使用 Google Snappy进行压缩。Snappy的特点是快,比大多数算法要快很多,而只牺牲了一点点压缩率。WiredTiger还支持zlib压缩,这样会比Snappy压缩率高一点点, 但速度慢很多。当然,你也可以设定为和MMAPv1一样, 不压缩。
## cache
WT引擎使用了二阶缓存WiredTiger Cache, File System Cache来保证Disk上的数据的最终一致性。
每隔60秒, 或当Journal文件超过2GB, 会有一个叫Checkpoints的事件, WT会把WT Cache中的数据存入FS Cache, 然后一次性将所有改变应用到磁盘上。换言之, 如果你既没有用Replica Set, 也没有用Journal。那么在你宕机的时候仍然能从最后一个Checkpoints恢复数据。

• 参考文献
  
  • mongo存储引擎
  • WiredTiger 和 MMAPv1的一些主要区别

2.2、微服务架构浅读

• 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
  
• 对应用组件封装的方式是整体架构与微服务架构的主要差异，微服务架构将相关联的业务逻辑及数据放在一起形成独立的边界，其目的是能在不影响其他应用组件(微服务)的情况下更快地交付并推出市场。
  
• 微服务的一些通用特性
  
  • 通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
  • 围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大。
  • 产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
  • 智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
  • “去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
  • 故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
  • 演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。
• 微服务的优点
  
  • 每个服务都比较简单，只关注于一个业务功能。
  • 微服务架构方式是松耦合的，可以提供更高的灵活性。
  • 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
  • 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
  • 微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
• 微服务的缺点
  
  • 运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
  • 必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
  • 隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
  • 代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复
  • 分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
  • 异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
  • 可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
• 推荐文章
  
  • 微服务设计与实践原则
  • 解析微服务架构(一)：什么是微服务
  • 解析微服务架构(二)：融入微服务的企业集成架构