目录

1、从单块系统说起

2、团队越来越大，业务越来越复杂

3、分布式出现：庞大系统分而治之

4、分布式系统所带来的技术问题

5、一句话总结：什么是分布式系统设计和开发经验

6、补充说明：中间件系统及大数据系统

 

前言

现在有很多Java技术方向的同学在找工作的时候，肯定都会去招聘网站上找职位投递简历。

 

但是在很多职位JD上往往会有这样的一个要求：熟悉分布式系统理论、设计和开发，具备复杂分布式系统构建经验。

 

之前不少同学后台留言问过我：这个分布式系统的设计和开发经验，到底指的是什么？那么这篇文章就给大家来解释一下这个问题。

 

 

1从单块系统说起

 

要说分布式系统是什么东西，那么就得先从单块系统开始说起。

 

很多同学应该都知道，如果你在一些中小型的传统软件公司里工作，那么很有可能现在在做的系统是如下这个样子。

 

所有的代码都在一个工程里，最多可能就是通过maven等构件工具拆分了一下代码工程模块，不同的模块可以放在不同的工程代码里。

 

在部署的时候，可能就是直接在线上的几台机器里直接放到里面的tomcat下来运行。

 

然后在web服务器前面可能会有一层负载均衡服务器，比如用nginx或者是其他的负载均衡设备。

 

很多流量很小的企业内部系统，比如OA、CRM、财务等系统，甚至可能就直接在一台机器的tomcat下部署一下。

 

然后直接配置一下域名解析，就可以让这个系统的可能几十个，或者几百个用户通过访问域名来使用这个软件了。

 

至于说系统的依赖大概来说很可能只有一个，那就是MySQL、Oracle等关系型数据库，可能会在某台机器上专门部署一个数据库，让应用系统来使用。

 

大家看看下面的图，体会一下这种单体架构。

 

这种系统在很多中小型公司里现在还是比较多的，就是典型的单块系统，所有代码在一个工程，部署在一个tomcat里即可，这里包含了系统所有的功能。

 

你哪怕就部署一台机器，这个系统也可以运行，只不过为了所谓的“高可用”，可能一般会部署两台机器，前面加一层负载均衡设备，这样其中一个机器挂了，另外一个机器上还有一个系统可以用。

 

 

2团队越来越大，业务越来越复杂

 

其实上面说的那种单块系统，如果是一个10人以内的小团队大家一起维护和开发一个用户数量不多，请求量不大的系统，也是没问题的，还挺方便的，对吧。

 

你搞一个代码仓库，然后就一份代码，每个人都在自己本地写代码，最后把代码合并一下，做做测试，然后就直接部署基于Tomcat来就可以了。

 

但是问题就在于说，如果你的团队超过了10个人，比如有20个人，甚至几十个人，上百个人要一起协作开发这个系统，然后里面的业务逻辑特别多，可能功能模块多达几百个。这个时候就麻烦了，你要是还用那种单块系统的模式，那肯定是很痛苦的。

 

因为几十个人维护一个单块系统，大家在一个工程里写代码，大量的冲突以及代码合并都会让人崩溃。

 

而且部署的时候会有各种冲突，比如某个功能模块要上线了，但是他必须得把整个单块系统所有的功能都回归测试一遍才敢上线。

 

因为大家的代码都在一个工程里，都是耦合在一起的，你修改了代码，必须全部测试一遍才能保证系统正常。

 

所以说这个时候，就必须想办法把系统改造成分布式系统了。

 

 

3分布式出现：庞大系统分而治之

 

这个时候就可以尝试把一个大的系统拆分为很多小的系统，甚至很多小的服务，然后几个人组成一个小组就专门维护其中一个小系统，或者每个人维护一个小服务。

 

简单来说，就是分而治之，这样每个人可以专注维护自己的代码。

 

然后不同的小系统自己开发、测试和上线，都不会跟别人耦合在一起，可以自己独立进行，非常的方便，大大简化了大规模系统的开发成本。

 

不同的子系统之间，就是通过接口互相来回调用，每个子系统都有自己的数据库，大家看下面的图。

 

 

4分布式系统所带来的技术问题

 

那么大家这个时候可以思考一下，如果你的公司是采用这种分布式系统的方式来构建公司的一个大规模系统的，那么这个时候会涉及到哪些技术问题？

 

（1）分布式服务框架 

 

你如果要让不同的子系统或者服务之间互相通信，首先必须有一套分布式服务框架。

 

也就是各个服务可以互相感知到对方在哪里，可以发送请求过去，可以通过HTTP或者RPC的方式。

 

在这里，最常见的技术就是dubbo以及spring cloud，当然大厂一般都是自己有服务框架

（2）分布式事务 

一旦你的系统拆分为了多个子系统之后，那么一个贯穿全局的分布式事务应该怎么来实现？

 

这个你需要了解TCC、最终一致性、2PC等分布式事务的实现方案和开源技术。

 

（3）分布式锁 

不同的系统之间如果需要在全局加锁获取某个资源的锁定，此时应该怎么来做？

 

毕竟大家不是在一个JVM里了，不可能用synchronized来在多个子系统之间实现锁吧，是不是？

 

（4）分布式缓存 

 

如果你原来就是个单块系统，那么你其实是可以在单个JVM里进行本地缓存就可以了，比如搞一个HashMap来缓存一些数据。

 

但是现在你有很多个子系统，他们如果要共享一个缓存，你应该怎么办？是不是需要引入Redis等缓存系统？

 

（5）分布式消息系统 

在单块系统内，就一个JVM进程内部，你可以用类似LinkedList之类的数据结构作为一个本地内存里的队列。

 

但是多个子系统之间要进行消息队列的传递呢？那是不是要引入类似RabbitMQ之类的分布式消息中间件？

 

（6）分布式搜索系统 

如果在单块系统内，你可以比如在本地就基于Lucene来开发一个全文检索模块，但是如果是分布式系统下的很多子系统，你还能直接基于Lucene吗？

 

明显不行，你需要在系统里引入一个外部的分布式搜索系统，比如Elasticsearch。

 

（7）其他很多的技术 

比如说分布式配置中心、分布式日志中心、分布式监控告警中心、分布式会话，等等，都是分布式系统场景下你需要使用和了解的一些技术。

 

因为沿用单块系统时代的那些技术已经不行了，比如说你单块系统的时候，直接在本地用一个properties文件存放自己的配置即可，日志也写到本地即可。

 

但是分布式时代呢？

 

你那么多的子系统，怎么共享同一份配置？怎么把各个系统的日志聚合写到一个地方来查看？

 

单块系统的时候，你一个web应用直接基于Servlet API提供的Session会话功能即可，那么分布式时代呢，你有N多个子系统如果要共享会话该怎么做？

5一句话总结：什么是分布式系统设计和开发经验？

 

其实分析完了之后，大家应该就大概知道了，招聘JD上写这个分布式系统的设计和开发经验，其实他是一个很大的主题，里面包含很多的内容。

 

你的系统一旦分布式了之后，通信、缓存、消息、事务、锁、配置、日志、监控、会话，等等各种原来单块系统场景下很容易解决的问题，都会变得很复杂，需要引入大量外部的技术。

 

所以你有没有参与过类似这样的一个大的分布式系统？你有没有基于各种技术解决过分布式系统场景下的各种技术问题？这就是人家希望和要求的分布式系统设计和开发的经验。如果大家还没接触过，建议多去学习一下。

 

6补充说明：中间件系统及大数据系统

 

最后给大家说明一点，一般这种招聘JD，如果是Java岗位要求分布式相关的经验，其实主要还是上面说的那些东西，他面向的是分布式的业务系统的构建。

 

但是其实分布式系统本身是一个非常复杂的话题，因为刚才说的只是一个分布式业务系统要依赖哪些技术来进行构建。

 

但是其实比如Kafka、Rocket等中间件，本身他也是分布式的，你要搞明白他们自己是如何实现分布式的，又是一个非常复杂的话题。

 

此外，像hadoop、spark、hbase等大数据系统，本身也都是世界上最最复杂的分布式系统，这又涉及到大数据领域的话题了，以后有机会可以单独聊聊。

从小白级到工作8年需要掌握的技术栈大概如下：

0-1年入门：

Java基础复盘（面向对象+Java的超类+Java的反射机制+异常处理+集合+泛型+基础IO操作+多线程+网络编程+JDK新特性）

Web编程初探（Servlet+MySQL数据库+商品管理系统实战）

SSM从入门到精通（Spring+SpringMVC+Mybatis+商品管理系统实战-SSM版+Git+Maven） SpringBoot快速上手（SpringBoot+基于SpringBoot的商品管理系统实战）

零距离互联网项目实战（Linux+Redis+双十一秒杀实战系统）

1-3年高工：

并发编程进阶（并发工具类实战+CAS+显示锁解析+线程池内部机制+性能优化）

JVM深度剖析（理解运行时数据区+堆外内存解读+JDK+内存泄漏问题排查+Arthas+GC算法和垃圾回收器+类加载机制等）

MySQL深度进阶 深入Tomcat底层（线程模型+性能调优）

3-5年资深：

数据库（调优+事务+锁+集群+主从+缓存等）

Linux（命令+生产环境+日志+Nginx等） 中间件&分布式（dubbo+MQ/kafka、ElasticSearch、SpringCloud等组件）

5-8年架构：

开源框架（Spring5源码+SpringMVC源码+Mybatis源码）

分布式架构（Zk实战+RabbitMQ+RocketMQ+Kafka）

高效存储（Redis+mongoDB+MySQL高可用+Mycat+Sharing-Sphere）

微服务架构（RPC+SpringBoot+SpringCloud Netflix+SpringCloud Alibaba+docker+k8s）

0—1年工作经验学习资源（全套的学习资源的免费获取方式：关注公众号：JavaAC，获取）

Java基础

SSM基础

SpringBoot两大项目实战：

①：企业级通用的后台系统（源码+视频已经上传GitHub）

②：实现京东电子商务商城（对于初学者这个可以做暂时的了解，以后可以深度研究）源码+视频已经上传GitHub

1—3年的高级工程师

多线程与高并发

深入理解JVM

MySQL优化解析

3—5年的资深工程师

数据库

Linux

消息中间件等等

5—8年高级架构师

spring源码

SpringMVC源码

MyBatis源码

RPC构建分布式

SpringCloud

综合性的项目实战①：用Spring Cloud 实现页面日访问量3000万的某平台微服务架构（源码已经上传）

②：亿级流浪多级缓存平台（源码已经上传）

1 前言

因为《猫科动物和企鹅在窗口外看机器人吃苹果》这出戏太美，很多公司都希望能全平台同时发布新版本app，还要能复用代码以降低开发成本。这迫使一部分已熟悉某个平台的先锋们转岗到另一个平台边学习边开发。最终有少部分人在每个战场都打拼过，从而能全盘考虑以设计出良好的可复用架构。
革命总会出新知，今天已有一些开源框架能应对同时在5大平台Mac OS X、Linux、Windows、Android、iOS上开发客户端，新人们可以不再过多关心系统底层的那些事儿。不过多学点还是有很大好处的，最简单地概括就是会发现大道归一，多种编程语言、系统API、开发工具其实都是解决同一堆问题。越新的方法越方便，可是却算不上越简单。在理解这些之后，就会对编程乃至程序员职业本身有了更深层的看法。
（想到什么写什么，其实远远没总结完）

2 开发

2.1 开发环境

程序员肯定喜欢集代码编辑、编译、打包等一体化的IDE。然而好的IDE都不跨平台，比起写代码，掌握所有平台的官方tool chain是一件比较无聊的事，可是又重要得必须去做。

作用/工具/平台	Windows	Max OS X、iOS	Android	Linux	跨平台
IDE	Visual Studio	Xcode	Eclipse / IntelliJ IDEA	无官方版	自己打造=跨平台代码编辑软件+快捷键+命令行工具
工程文件	VS、Makefile	xcodeproj	Java IDE的、Android.mk	Makefile	cmake、gyp
代码编辑	可用IDE	可用IDE	可用IDE	无主流	Vim、Emacs、Sublime Text、Eclipse
命令行编译	cl、devenv、nmake	xcode-build（以前是gcc，现在是clang）	ant、ndk-build、gradle	gcc、make	gcc、clang
调试	VS、WinDbg	Xcode（GDB、LLDB）	JDB、GDB	GDB	无
打包	Windows Installer、第三方工具	Xcode+zip	aapt	dpkg、checkinstall	无

很多好用的工具是某平台特有的，可以帮助检查多平台共有的部分代码，如Linux下的valgrind帮助检查内存泄露，Xcode自带Analyze静态检测代码等。
无论是什么工具，查阅说明文档和用户手册是最基本的工作。因为信息量太大且应用场景过于局限，会难有做笔记的动力，用到什么就查什么，多查几次自然就记住了。
如果一段时间内都用同一种工具，记住功能、快捷键、面板设置等能大大加快工作效率。
如果是人力资源充足，最好能有专人负责所有平台的基础设施建设，而不是一个平台一个专家。在这方面研究透彻，后面的工作会事半功倍。

另外，跨平台开发肯定会用到虚拟机（Virtual Box或VMWare）。利用磁盘共享功能，可以修改代码后立刻在多个平台编译调试。推荐以Linux为Host，因为它工具多、系统性能高，能让工作效率最大化。

2.2 编程语言

理论上说，可以用C/C++写遍全平台（有转译神器的语言就不提了）。然而除非是自虐，否则没什么理由不在Android和iOS上分别用到一些Java和Objective-C，因为那样更容易调用便利的系统API。总之，做跨平台开发是不能只懂C/C++的。
而且，一般会用到脚本做一些自动化处理，例如检查代码规范、按文件模板生成代码、按配置打包资源文件等。目前流行的是python，因为它跨平台。跨平台的另外还有perl和ruby。如果算上Cygwin的帮助，那么shell就不仅仅是*nix专用的脚本语言了。不跨平台的话，Windows是batch file，Mac是AppleScript。
如果不幸碰上客户端需要显示网页（移动端上使用WebView），还少不了要懂点HTML/CSS/JavaScript。

语言学多了，会发现有许多共通点。

编程语言的最终目标都是为了生成CPU指令，只不过是承担了越多工作的编程语言，需要程序员写的代码越少而已。形象点说就是所有语言都是汇编的子孙，基因大部分是相同的，长得胖的穿衣服少罢了。所以，随着语言越学越多，每学一种新的都会越快上手。
学多了会混乱，编程书籍或网页参考常备身边是个好办法。

除了C++，各种语言都已和操作系统结合或者封装了系统的底层调用，以另外的模块/包的形式提供线程、进程等操作。越新的语言屏蔽了越多操作系统的细节，连C++11开始也提供了线程的操作。

另外，动态语言的特性在客户端开发的过程中被广泛利用。主要目的是解耦和调试。

1. Objective-C动态语言的特性
2. Java的反射
3. 跨编程语言调用
   
   • C++调用命令行
   • JNI
   • python调用C/C++

2.3 操作系统

编程语言用到极致，最多也只能做纯数据运算。程序与外部交互的媒介是操作系统，所以跨平台开发还是得熟悉各个操作系统的特性。编程到了一定阶段，查系统SDK/API的用法会成为常态。最后你会发现，无非也就这几类：

1. 窗口
2. 进程与进程间通讯
3. 原子操作与锁
4. 线程与线程本地存储
5. 消息循环
6. 绘图/排版/动画/矢量图
7. 文件读写
8. 网络与协议
9. 时间与日期
10. 用户事件（鼠标、键盘、触碰）
11. 设备事件（USB、陀螺仪、GPS、显示器/屏、电量等）
12. 影音播放
13. 动态库
14. 权限、安全、验证
15. 驱动与内核

使用第三方库能简化系统API和弥补不足，例如boost库能屏蔽很多系统API的差异，并有很多强大的工具。然而不能期望第三库能满足所有的需求，需要自己开发特定需要的库并不断积累，或许有一天还能贡献反哺给开源社区。
如果是做游戏客户端，以上需要关心的东西会更少，除非重新写一个游戏引擎。

为了符合平台用户体验、效能效率最优化、提升开发速度等目的，有时候我们必须使用特定操作系统的功能与界面，所以并不是对系统浅浅了解即可。根据开发的目标不同（特别是涉及硬件的），有时候还要挖掘底层API来用。

程序的一些额外处理：多语言、配置管理、初始化……

2.4 一些跨平台编程的坑

每个平台的坑都多如牛毛，是程序就有缺陷。举几个例子：
Windows带来的宏，如max、AddJob，这些不能作为函数名，否则Linux编译过了Windows会不过。

---

size_t在printf中的表示，Linux是%zu，Windows是%lu，没有通用的。当然，可以把这些warning关掉。

---

在linux平台能稳定运行的代码，在windows不一定行。例如

const char* GetString() {
  std::string temp = "1234";
  return temp.c_str();
}

因为STL的实现可能不同。还有系统内存回收机制也不同。

---

有些库只是特定平台需要，zlib（libz）就只有Windows需要。其余系统有自带的。

---

还有一些不算坑，仅算差异，但为了全平台能编译得过，仍需要记住。例如DEBUG宏不是所有平台都有的，动态库的接口导出写法不同：

#if defined(WIN32)
#  if defined(MY_IMPLEMENTATION)
#    define MY_EXPORT __declspec(dllexport)
#  else
#    define MY_EXPORT __declspec(dllimport)
#  endif
#else
#  if defined(MY_IMPLEMENTATION)
#    define MY_EXPORT __attribute__((visibility("default")))
#  else
#    define MY_EXPORT
#  endif
#endif

3 维护

3.1 架构设计

把架构设计放在维护这节是故意的，因为在跨平台产品中，可维护性是一切变态需求和bug的救星，这正正体现了架构设计的价值。
设计的结果基本上都是把程序分为三大层，从低到高是：平台无关层->平台抽象层->平台相关（适配）层。一些特定平台有的feature会作为component穿插到适配层中。

平台无关层包含数据处理和逻辑控制。数据处理是指通用数据描述（XML、JSON、Google ProtocolBuf），持久化存储，字符编码/多语言/国际化（ICU），图片解码，音频/视频解码，资源管理，log等。逻辑控制多是业务流程的实现。

平台抽象层把平台间有差异的部分做抽象，由平台相关层实现。这层是最考验设计功底的。

平台相关层多数跟UI有关，少数是此平台的特色业务需要，在移动端有衔接编程语言的作用。移动端会使用系统UI构件以求符合对应的用户体验，而且这些构件不是C++的。
当然，UI部分也能复用跨平台，不使用系统构件，完全自绘。这个方案的另一个好处就是容易换肤。不过系统构件一般都有硬件加速，自绘的性能相对较低。

更细致的划分就叫模块了。

3.2 测试与自动化

移动端是各平台的测试中最麻烦的，然而越是苛刻越是以那个平台为准。
如果由人工来保证每个平台都时刻正常那几乎是不可能的，所以要很多检测和测试需要依赖自动化。例如：

1. 静态代码分析。如Xcode的Analyze。还可能做代码规范的检测，如cpplint。C++的代码自动格式化可以用clang-format.
2. 编译与打包通过性测试。
3. 单元测试、集成测试、系统测试、Monkey测试等，这些测试包含了兼容性测试。
4. 内存泄漏检测。如Linux下的Valgrind、LLVM提供的ASan、Xcode的Leaks等。
5. 性能测试。

为了实现这些测试，也是要写代码的。至少集成测试就没有通用的，要自己写。为了完成这些测试，又少不了用到各种第三方代码和工具。

自动化平台的工具推荐用buildbot。
从测试工具的举例可以看到，跨平台代码可以被多个特定平台才有的工具检测，对可靠性有非常大的帮助。

3.3 发布后

一般要做三件事：

1. 崩溃日志收集以及log自动化分析。可以使用Google的breakpad。
2. 统计信息与运营分析。
3. 程序更新通知与信息推送。

这些是需要客户端配合的，但主要的工作量在后台。点到为止。
多平台共同开发有个好处：iOS的发布麻烦，及时发现bug慢，可以先在Android发布来弥补。

4 收获

坦白讲，最终的收获不怎么有趣，因为你看清了现实；然而又有些兴奋，因为下一步可能是创造新世界。
看清现实：

1. 其实无论使用哪种语言或者在哪个操作系统编程都一样，虽然解决的问题不同，但手段是相似的，大道归一，程序的世界就是0和1。
2. 做客户端应用程序开发，实际就是在使用各种API，极致境界是开发驱动程序和研究系统原理。
3. 为了更好地开发，有很多“开发支持”领域中的事情不得不做，不少也是要写代码的。
4. 程序最终是为产品服务的。软件的创新最终会是内容和功能的创新，“制作”本身终会到达瓶颈。

创造新世界：

1. 最优架构设计或最优算法。（对，这就是程序员走向架构师的理由，不想继续Ctrl C+Ctrl V了）
2. 各种新工具的开发，为提升效率而努力。
3. 开发一门跨平台语言或者一个新系统？对技术有追求的，可以紧跟时代脉搏，学尽各种新语言，了解语言的趋势。最厉害的当然是发明一种新语言（及其配套的编译、调试工具）甚至一种操作系统了，不知道有生之年能不能看到中国人的发明呢。
4. 知道了“怎样”编程，代码都写腻了，对编“什么样”的程序产生了兴趣，要转岗产品经理试试吗？

后续补充：《客户端开发设计总结》
http://blog.csdn.net/hursing/article/details/52586541

转载请注明出处：http://blog.csdn.net/hursing

嗯，干完跨平台项目就是这个样子：