本文原作者“虞大胆的叽叽喳喳”，原文链接：jianshu.com/p/8861da5734ba，感谢原作者。

1、引言

很多人一提到 HTTPS，第一反应就是安全，对于普通用户来说这就足够了；

但对于程序员，很有必要了解下 HTTP 到底有什么问题？以及HTTPS 是如何解决这些问题的？其背后的解决思路和方法是什么？

本文只做简单的描述，力求简单明了的阐明主要内容，因为HTTPS 体系非常复杂，这么短的文字是无法做到很详细和精准的分析。想要详细了解HTTPS的方方面面，可以阅读此前即时通讯网整理的《即时通讯安全篇（七）：如果这样来理解HTTPS，一篇就够了》一文。

（本文同步发布于：http://www.52im.net/thread-2027-1-1.html）

2、HTTPS相关文章

《即时通讯安全篇（七）：如果这样来理解HTTPS，一篇就够了》

《一文读懂Https的安全性原理、数字证书、单项认证、双项认证等》

《HTTPS时代已来，打算更新你的HTTP服务了吗？》

《苹果即将强制实施 ATS，你的APP准备好切换到HTTPS了吗？》

3、对HTTPS性能的理解

HTTP 有典型的几个问题，第一就是性能，HTTP 是基于 TCP 的，所以网络层就不说了（快慢不是 HTTP 的问题）。

比较严重的问题在于 HTTP 头是不能压缩的，每次要传递很大的数据包。另外 HTTP 的请求模型是每个连接只能支持一个请求，所以会显得很慢。

那么 HTTPS 是解决这些问题的吗？

不是，实际上 HTTPS 是在 HTTP 协议上又加了一层，会更慢，相信未来会逐步解决的。同时 HTTPS 用到了很多加密算法，这些算法的执行也是会影响速度的。

为什么说 HTTPS 提升了性能呢？因为只有支持了 HTTPS，才能部署 HTTP/2，而 HTTP/2 协议会提升速度，能够有效减轻客户端和服务器端的压力，让响应更快速。有关HTTP/2详细文章可以看看《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》、《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》，这里只要知道一点：HTTP/2 能够加快速度的主要原因在于多路复用，同一个连接能够并行发送和接收多个请求。

4、传统HTTP的安全性问题

当用户在浏览器输入一个网址的时候，在地址栏上看到小锁图标，就会安心，潜意识的认为自己的上网行为是安全的，当然对于小白用户来说可能还不明白，但是未来会慢慢改善的（万事开头难嘛）。

那么 HTTP 到底有什么安全问题呢，看几个例子：

1）由于互联网传输是能够被拦截的，所以假如你的上网方式被别人控制了（没有绝对的安全），那么你的任何行为和信息攻击者都会知道，比如我们连上一个匿名的 WIFI，当你上网的时候，输入的网站密码可能就已经泄漏了；

2）当我们在上一个网站的时候，莫名其妙跳出一个广告（这个广告并不是这个网站的），那是因为访问的页面可能被运营商强制修改了（加入了他自己的内容，比如广告）。

HTTP 最大的问题就在于数据没有加密，以及通信双方没有办法进行身份验证（ confidentiality and authentication），由于数据没有加密，那么只要数据包被攻击者劫持，信息就泄漏了。

身份验证的意思就是服务器并不知道连接它的客户端到底是谁，而客户端也不确定他连接的服务器就是他想连接的服务器，双方之间没有办法进行身份确认。

有关HTTP比较好的文章，可以看看：

《网络编程懒人入门(七)：深入浅出，全面理解HTTP协议》

《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》

《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》

5、HTTPS 背后的密码学

为了解决 HTTP 的两个核心问题，HTTPS 出现了，HTTPS 包含了核心的几个部分：TLS 协议、OpenSSL，证书。

什么是 OpenSSL 呢，它实现了世界上非常重要和多的密码算法，而密码学是解决问题最重要的一个环节。

TLS 最重要的是握手的处理方式。证书的体系也很大，但是他们背后都是基于同样的密码学。

1）既然 HTTP 没有数据加密，那么我们就加密下，对称加密算法上场了，这种算法加密和解密要使用同一个密钥，通信双方需要知道这个密钥（或者每次协商一个），实际上这种方法不太可能，这涉及到密钥保密和配送的问题，一旦被攻击者知道了密钥，那么传输的数据等同没有加密。

2）这个时候非对称加密算法上场了，公钥和私钥是分开的，客户端保存公钥，服务器保存私钥（不会公开），这时候好像能够完美解决问题了。

但实际上会存在两个问题，第一就是非对称加密算法运算很慢，第二就是会遇到中间人攻击问题。

先说说中间人攻击的问题，假如使用非对称加密算法，对于客户端来说它拿到的公钥可能并不是真正服务器的公钥，因为客户端上网的时候可能不会仔细分辨某个公钥是和某个公司绑定的，假如错误的拿到攻击者的公钥，那么他发送出去的数据包被劫持后，攻击者用自己的私钥就能反解了。

3）接下来如何解决公钥认证的问题呢？证书出现了，证书是由 CA 机构认证的，客户端都充分信任它，它能够证明你拿到的公钥是特定机构的，然后就能使用非对称加密算法加密了。

证书是怎么加密的呢？实际上也是通过非对称加密算法，但是区别在于证书是用私钥加密，公钥解密。

CA 机构会用自己的私钥加密服务器用户的公钥，而客户端则用 CA 机构的公钥解出服务器的公钥。听上去有点晕，仔细体会下。这方面的知识，可以详细阅读：《即时通讯安全篇（七）：如果这样来理解HTTPS，一篇就够了》。

4）上面说了非对称加密算法加密解密非常耗时，对于 HTTP 这样的大数据包，速度就更慢了，这时候可以使用对称加密算法，这个密钥是由客户端和服务器端协商出来，并由服务器的公钥进行加密传递，所以不存在安全问题。

5）另外客户端拿到证书后会验证证书是否正确，它验证的手段就是通过 Hash 摘要算法，CA 机构会将证书信息通过 Hash 算法运算后再用私钥加密，客户端用 CA 的公钥解出后，再计算证书的 Hash 摘要值，两者一致就说明验证身份通过。

6）HTTPS 解决的第三个问题是完整性问题，就是信息有没有被篡改（信息能够被反解），用的是 HMAC 算法，这个算法和 Hash 方法差不多，但是需要传递一个密钥，这个密钥就是客户端和服务器端上面协商出来的。

附录：更多安全方面的文章

《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》

《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》

《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》

《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》

《即时通讯安全篇（五）：对称加密技术在Android平台上的应用实践》

《即时通讯安全篇（六）：非对称加密技术的原理与应用实践》

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》

《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》

《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》

《简述实时音视频聊天中端到端加密（E2EE）的工作原理》

《移动端安全通信的利器——端到端加密（E2EE）技术详解》

《Web端即时通讯安全：跨站点WebSocket劫持漏洞详解(含示例代码)》

《通俗易懂：一篇掌握即时通讯的消息传输安全原理》

《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》

《快速读懂量子通信、量子加密技术》

《即时通讯安全篇（七）：如果这样来理解HTTPS原理，一篇就够了》

《一分钟理解 HTTPS 到底解决了什么问题》

>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-2027-1-1.html）

本文引用了阿豪的微信公众号文章分享，感谢原作者的分享。

1、前言

随着社会的发展、互联网技术的进步，以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了，替代它的就是当下最火的互联网分布式架构。

从若干年前大行其道的传统大型机到如今的分布式架构，技术发展已经经历了好几个阶段，我们只有弄明白典型互联网架构在各个阶段的演进，才能更好地理解和体会分布式架构的好处，从而有助于我们序设计适合于自已公司、产品或项目的架构（也包括设计即时通讯网专注的IM和消息推送这类系统，因为技术思路的原理都是一脉相承的）。那么本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。

点评：即时通讯网作为IM和推送技术研究、学习和分享的社区，整理了大量的跟IM和推广技术有关的基础技术资料（比如网络基础、通信理论、架构基础等），本文内容虽然看起来跟IM和推送技术没有直接的关联性，但因为设计IM和推送系统的技术思路和原理跟典型大型互联网分布式架构都是一脉相承的，因而读懂本文内容对于IM和推送系统的架构设计同样大有裨益。

学习交流：

- 即时通讯开发交流3群：185926912[推荐]

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

（本文同步发布于：http://www.52im.net/thread-2007-1-1.html）

2、相关文章

如果你已完全掌握本文的相关知识，请移步继续阅读即时通讯网整理的另一篇：《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》，该文适合对互联网架构知识有一定了解的程序员阅读和学习，都是不可能多得的技术干货。

3、技术背景说明

我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的。 在这个过程中，开发模式、技术架构等都会随着迭代发生非常大的变化。 而针对不同业务特征的系统，各自都会有自己的侧重点，例如像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。

为了方便展开本文要讲解的内容，我们来简单模拟一个架构演变过程： 我们以 javaweb 为例，来搭建一个简单的电商系统，从这个系统中来看系统的演变过程。要注意的是接下来的演示模型， 关注的是数据量、访问量提升，网站结构的变化， 而不关注具体业务的功能点。其次，这个过程是为了让大家能更好的了解网站演进过程中的一些问题和应对策略。

假如我们要设计的互联网系统需要具备以下功能:

1）用户模块：用户注册和管理；

2）商品模块:商品展示和管理；

3）交易模块:创建交易及支付结算。

请带着上述3个技术点，继续深入阅读本文的正文内容。干货马上开始了。。。

4、架构演进阶段一：单应用架构

如上图所示，这个阶段是网站的初期，也可以认为是互联网发展的早期，系统架构如上图所示。我们经常会在单台服务器上运行我们所有的程序和软件。 把所有软件和应用都部署在一台机器上，这样就完成一个简单系统的搭建，这个阶段的讲究的是效率。效率决定生死。

5、架构演进阶段二：应用服务器和数据库服务器分离

随着网站的上线，访问量逐步上升，服务器的负载慢慢提高，我们应该在服务器还没有超载的时候就做好规划、提升网站的负载能力。假若此时已经没办法在代码层面继续优化提高，那么在单台机器的性能遇到瓶颈的时候，增加机器是一个比较简单好用的方式，投入产出比相当高。这个阶段增加机器的主要目的是将 web 服务器和 数据库服务器拆分开来，这样做的话不仅提高了单机的负载能力，也提高了整个系统的容灾能力。

这个阶段的系统架构如上图所示，应用服务器和数据库服务器完全隔离开来，相互互不影响，大大减少了网站宕机的风险，此阶段我们已经开始关注到应用服务器的管理了。 

6、架构演进阶段三：应用服务器集群

这个阶段，随着访问量的继续不断增加，单台应用服务器已经无法满足我们的需求。 假设我的数据库服务器还没有遇到性能问题，那我们可以通过增加应用服务器的方式来将应用服务器集群化，这样就可以将用户请求分流到各个服务器中，从而达到继续提升系统负载能力的目的。此时各个应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。

系统架构发展到这个阶段，各种问题也会接踵而至：

1）用户请求交由谁来转发到具体的应用服务器上(谁来负责负载均衡)；

2）用户如果每次访问到的服务器不一样，那么如何维护session，达到session共享的目的。

那么此时，系统架构又会变成如下方式：

负载均衡又可以分为软负载和硬负载。软负载我们可以选择Nginx、Apache等，硬负载我们可以选择F5等。而session共享问题我们可以通过配置tomcat的session共享解决。

7、架构演进阶段四：数据库压力变大，数据库读写分离

架构演变到上面的阶段，并不是终点。通过上面的设计，应用层的性能被我们拉上来了， 但数据库的负载也在逐渐增大，那如何去提高数据库层面的性能呢？有了前面的设计思路以后，我们自然也会想到通过增加服务器来提高性能。但假如我们单纯的把数据库一分为二，然后对于数据库的请求，分别负载到两台数据库服务器上，那必定会造成数据库数据不统一的问题。 

所以我们一般先考虑将数据库读写分离，如下图所示。

这个架构设计的变化会带来如下几个问题：

1）主从数据库之间的数据需要同步(可以使用 mysql 自带的 master-slave 方式实现主从复制 )；

2）应用中需要根据业务进行对应数据源的选择( 采用第三方数据库中间件，例如 mycat )。

8、架构演进阶段五：使用搜索引擎缓解读库的压力

我们都知道数据库常常对模糊查找效率不是很高，像电商类的网站，搜索是非常核心的功能，即使是做了读写分离，这个问题也不能得到有效解决。那么这个时候我们就需要引入搜索引擎了，使用搜索引擎能够大大提升我们系统的查询速度，但同时也会带来一 些附加的问题，比如维护索引的构建、数据同步到搜索引擎等。

9、架构演进阶段六：引入缓存机制缓解数据库的压力

然后，随着访问量的持续不断增加，逐渐会出现许多用户访问同一内容的情况，那么对于这些热点数据，没必要每次都从数据库重读取，这时我们可以使用到缓存技术，比如 redis、memcache 来作为我们应用层的缓存。

另外在某些场景下，如我们对用户的某些 IP 的访问频率做限制， 那这个放内存中就又不合适，放数据库又太麻烦了，那这个时候可以使用 Nosql 的方式比如 mongDB 来代替传统的关系型数据库。

10、架构演进阶段七：数据库的水平/垂直拆分

我们的网站演进的变化过程，交易、商品、用户的数据都还在同一 个数据库中，尽管采取了增加缓存，读写分离的方式，但是随着数 据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我 们可以考虑对数据的垂直拆分和水平拆分。

垂直拆分：把数据库中不同业务数据拆分到不同的数据库；

水平拆分：把同一个表中的数据拆分到两个甚至更多的数据库中，水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈，这时可以采取将表拆分到多个数据库中。

11、架构演进阶段八：应用的拆分

随着业务的发展，业务量越来越大，应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑将应用拆分，按照领域模型将我们的用户、商品、交易拆分成多个子系统。

这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品和交易都需要查询，所以会导致每个系统都会有用户查询访问相关操作。这些相同的操作一定是要抽象出来，否则就是一个坑。所以通过走服务化路线的方式来解决。

那么服务拆分以后，各个服务之间如何进行远程通信呢? 通过 RPC 技术，比较典型的有:dubbo、webservice、hessian、http、RMI 等等。前期通过这些技术能够很好的解决各个服务之间通信问题，但是， 互联网的发展是持续的，所以架构的演变和优化也还在持续。

12、本文小结

通过本文，我们通过一个电商的案例，就了解到了分布式架构的演进过程，一环套一环，环环紧密相扣。都是通过业务量和访问量的提升来考虑重构架构设计，以便能够适应当前的环境。不可一蹴而就，也急不来，初创企业必须稳扎稳打，一步一个脚印的走出一条专属自己的路。

本文主要针对的是零基础初学者，如果您想深入了解相关知识，请继续阅读《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》。

附录：更多架构方面的技术文章

《浅谈IM系统的架构设计》

《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》

《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》

《一套原创分布式即时通讯(IM)系统理论架构方案》

《从零到卓越：京东客服即时通讯系统的技术架构演进历程》

《蘑菇街即时通讯/IM服务器开发之架构选择》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信技术总监谈架构：微信之道——大道至简(演讲全文)》

《如何解读《微信技术总监谈架构：微信之道——大道至简》》

《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》

《17年的实践：腾讯海量产品的技术方法论》

《移动端IM中大规模群消息的推送如何保证效率、实时性？》

《现代IM系统中聊天消息的同步和存储方案探讨》

《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》

《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》

《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》

《WhatsApp技术实践分享：32人工程团队创造的技术神话》

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》

《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》

《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》

《以微博类应用场景为例，总结海量社交系统的架构设计步骤》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》

《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》

《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-2007-1-1.html）

1、MMKV简介

腾讯微信团队于2018年9月底宣布开源 MMKV ，这是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，主打高性能和稳定性。近期也已移植到 Android 平台，一并对外开源。

MMKV 是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今，在 iOS 微信上使用已有近 3 年，其性能和稳定性经过了时间的验证。近期也已移植到 Android 平台，一并开源。

MMKV最新源码托管地址：https://github.com/Tencent/MMKV

2、MMKV 源起

在微信客户端的日常运营中，时不时就会爆发特殊文字引起系统的 crash（请参见文章：《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》、《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》），文章里面设计的技术方案是在关键代码前后进行计数器的加减，通过检查计数器的异常，来发现引起闪退的异常文字。在会话列表、会话界面等有大量 cell 的地方，希望新加的计时器不会影响滑动性能；另外这些计数器还要永久存储下来——因为闪退随时可能发生。

这就需要一个性能非常高的通用 key-value 存储组件，我们考察了 SharedPreferences、NSUserDefaults、SQLite 等常见组件，发现都没能满足如此苛刻的性能要求。考虑到这个防 crash 方案最主要的诉求还是实时写入，而 mmap 内存映射文件刚好满足这种需求，我们尝试通过它来实现一套 key-value 组件。

3、MMKV 原理

内存准备：

通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统负责将内存回写到文件，不必担心 crash 导致数据丢失。

数据组织：

数据序列化方面我们选用 protobuf 协议，pb 在性能和空间占用上都有不错的表现。

写入优化：

考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力。我们考虑将增量 kv 对象序列化后，append 到内存末尾。

空间增长：

使用 append 实现增量更新带来了一个新的问题，就是不断 append 的话，文件大小会增长得不可控。我们需要在性能和空间上做个折中。

更详细的设计原理参考MMKV 原理。

4、iOS 指南

安装引入（推荐使用 CocoaPods）：

安装CocoaPods；

打开命令行,cd到你的项目工程目录, 输入pod repo update让 CocoaPods 感知最新的 MMKV 版本；

打开 Podfile, 添加pod 'MMKV'到你的 app target 里面；

在命令行输入pod install；

用 Xcode 打开由 CocoaPods 自动生成的.xcworkspace文件；

添加头文件#import <MMKV/MMKV.h>，就可以愉快地开始你的 MMKV 之旅了。

更多安装指引参考iOS Setup。

快速上手：

MMKV 的使用非常简单，无需任何配置，所有变更立马生效，无需调用synchronize:

MMKV *mmkv = [MMKV defaultMMKV];    [mmkvsetBool:YESforKey:@"bool"];BOOL bValue = [mmkvgetBoolForKey:@"bool"];    [mmkvsetInt32:-1024forKey:@"int32"];int32_t iValue = [mmkvgetInt32ForKey:@"int32"];    [mmkvsetObject:@"hello, mmkv"forKey:@"string"];NSString *str = [mmkvgetObjectOfClass:NSString.classforKey:@"string"];

更详细的使用教程参考iOS Tutorial。

性能对比：

循环写入随机的int1w 次，我们有如下性能对比：

更详细的性能对比参考iOS Benchmark。

5、Android 指南

安装引入：

推荐使用 Maven：

dependencies{implementation'com.tencent:mmkv:1.0.10'// replace"1.0.10"with any available version}

更多安装指引参考Android Setup。

快速上手：

MMKV 的使用非常简单，所有变更立马生效，无需调用sync、apply。 在 App 启动时初始化 MMKV，设定 MMKV 的根目录（files/mmkv/），例如在 MainActivity 里：

protectedvoidonCreate(Bundle savedInstanceState){super.onCreate(savedInstanceState);    String rootDir = MMKV.initialize(this);    System.out.println("mmkv root: "+ rootDir);//……}

MMKV 提供一个全局的实例，可以直接使用：

importcom.tencent.mmkv.MMKV;//……MMKV kv = MMKV.defaultMMKV();kv.encode("bool",true);booleanbValue = kv.decodeBool("bool");kv.encode("int", Integer.MIN_VALUE);intiValue = kv.decodeInt("int");kv.encode("string","Hello from mmkv");String str = kv.decodeString("string");

MMKV 支持多进程访问，更详细的用法参考Android Tutorial。

性能对比：

循环写入随机的int1k 次，我们有如下性能对比：

更详细的性能对比参考Android Benchmark。