在上一篇文章中有同学留言，希望可以再分享微服务和分布式方面的具体知识，于是便有了这篇新文章的“问世”。在阅读本文之前，请确保有一定的网络基础，熟练使用Linux，浏览大概需要3-5分钟的时间。

这篇文章主要目的是面向初接触微服务的朋友简单介绍微服务基础建设所需要的各个模块以及缘由。

简单回顾一下过去三年微服务的发展历程。在过去三年当中，微服务成为我们的业界技术热点，我们看到大量的互联网公司都在做微服务架构的落地。也有很多传统企业在做互联网技术转型，基本上还是以微服务和容器为核心。

本文内容来源于任伟在【沪江技术沙龙】-漫谈微服务架构实践上的主题演讲，IT大咖说为沪江技术沙龙独家视频知识分享平台。 内容摘要Bilibili作为一个大型弹幕视频网站，在竞争日益激烈的互联网行业中，开始重视技术生态的演进，探索寻求适合企业本身的一个微服务架构。本次分享主要讲述了…

随着自动化运维等相关技术的发展，微服务变得更容易管理，这给了微服务架构良好的发展机会；同时，Docker 等容器技术的发展，使微服务架构的落地变得更加方便，这更是为其成为主流技术铺好了道路。目前各家对微服务架构都有自己的理解与落地实践。 本次InfoQ采访到58到家技术委员…

上周六参加了魔窗组织的一个线上跨境茶话会Live的交流活动，主题是《微服务的挑战》，虽然另外两位嘉宾和我的背景各不相同，所在的企业的业务也完全不一样，但是聊到后面，大家的观点还是基本一致的。针对里面的环节，选取了“微服务拆分”这个小议题，做了一个小结，谈谈个人的一点看法。 首先…

1、I/O优化 1、增加缓存，减少磁盘的访问次数。 2、优化磁盘的管理系统，设计最优的磁盘方式策略，以及磁盘的寻址策略，这是在底层操作系统层面考虑的。 3、设计合理的磁盘存储数据块，以及访问这些数据库的策略，这是在应用层面考虑的。例如，我们可以给存放的数据设计索引，通过寻址

传统单体架构将系统分成具有不同职责的层次，对应的项目管理也倾向于将大的团队分成不同的职能团队，主要包括：用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。每个团队只对自己分层的职责负责，并对使用方提供组件服务质量保证。如果其中一个模块化组件需要升级、更新，那么这个变更会涉及不同的分层团队，即使升级和变更的改变很小，也需要进行跨团队沟通：需求阶段需要跨团队沟通产品功能，设计阶段需要跨团队沟通设计方案，开发阶段需要跨团队沟通具体的接口定义，测试阶段需要沟通业务回归等事宜，甚至上线都需要跨团队沟通应用的上线顺序。可见在传统的整体架构下，后期的维护成本很高，出现事故的风险很大。