来源|Kevin改变世界的点滴
做产品经理，在工作中经常有做“产品框架”的需求
它要求了我们要基于业务现在、放眼未来的变化，设计出符合业务生命周期、用户生命周期的产品框架。
可是产品框架式是离不开技术基础的。
比如曾经微信、米聊相互竞争的案例下，当初小米的米聊在产品有先发优势，但是却在后期输给了微信。
其中一个原因是， 腾讯有过QQ这样的数十亿用户的产品，具备高并发技术栈的优势。而小米始终没有做过这样上亿注册量、活跃的产品。所以也就没有办法快速的实现用户高量下的更好用户体验。
产品的活跃用户量大规模增加后，对应页面加载方式、服务器配置、网络带宽等，都要求越来越高，否则访问速度、系统性能都会降低，从而影响用户体验。
后面事后采访中，雷军也提到：“这是他们应该赚的钱，我们不擅长”。
所以，如果离开了技术基础知识，产品框架只是一个空纸。
所以产品经理需要了解一些技术基础知识甚至是技术架构，才能够做出好用的产品框架。
而这里的技术知识我们包含了语言知识、以及技术架构知识。
1.产品经理要了解的技术架构
1.什么是技术架构
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策，架构也是产品的结构和愿景。
系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。
2.架构的种类
架构可以分为逻辑架构、物理架构、系统架构
逻辑架构：
软件系统当中的各个元件之间所存在的关系，比如外部系统接口、用户界面、商业逻辑元件、数据库等
物理架构：
软件元件分布式系统的物理架构，所有元件都是属于物理设备，主要有主机、整合服务器、英语服务器、代理服务器、存储服务器、报表服务器web服务器、网络分流器等。
系统架构：
基于各个不同的角度进行分析，都能够了解到划分元件、决定设计这个两个架构的要素
3.架构案例：单体架构和微服务
在早期大部分应用不会考虑到技术架构，因为要落地一个技术架构是非常需要开发时间和资源的，而应用早期首先考虑的是功能闭环、以及解决实际问题的验证。但随着用户增加和性能的要求，则需要进行技术架构的重构，比较常见的案例就是将单体应用架构改为微服务架构。什么是单体应用程序：
应用程序的全部功能被一起打包作为单个单元或应用程序.这个单元可以是JAR、WAR、EAR,或其他一些归档格式,但其全部集成在一个单一的单元.
什么是微服务：
微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
单体应用优点：
1.方便调试，代码都在一起；
2.没有分布式开销，所有服务都在本地容器内；
3.中小型项目可以快速迭代，不需要太多资源。
单体应用缺点：
1.可复用性差：服务被打包在应用中，功能不易复用；
2.系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长。
3.线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级。
微服务架构的优点
1.分而治之；单个服务功能内聚，复杂性低；方便团队的拆分和管理；
2.单独部署，独立开发；
微服务架构的缺点
1.开发难度大；垮服务的调用通常是不同的机器，甚至是不同的机房，开发人员需要处理超时、网络异常等问题。
2.效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期。
3.需要分布式事务的支持。
2.产品经理去了解的开发语言知识
为了满足市面上业务的特点，科技企业会选择不同的开发语言，现阶段市面主要是C、PHP、java等为主，而产品经理至少要了解到主流的语言特点与函数。
1.c语言
主要用于那些对效率要求很高的地方，比如说电脑的各种驱动程序，或者机械制造方面的应用。
2.java语言
桌面应用的j2se，企业应用j2ee，手机应用j2me。桌面应用的话，可以写一些小游戏：贪吃蛇、俄罗斯方块等，后缀名是.jar。企业应用的话，就是说公司里面用的一些管理软件，网站也可以，我记得好像校内网就是用java做的。
3.PHP语言
主要应用于Web开发领域，这两门编程语言在应用场景上几乎没有交叉，所以也相对比较好选择。
以上并不是要求产品经理要去从事研发工作，但最好的方式是经验积累，比如是多和后端开发沟通，在多个案例后逐渐不同语言的开发优势
3.产品经理要了解的系统架构图
系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。
一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。
下面有主要5类架构图，值得产品经理收藏
1.场景图表
用户描述系统的参与者与功能用例之间的关系没反应系统的最终需求和交互设计
2.逻辑图表
用于描述系统软件功能拆解后的组件关系，组件约束和边界，反应系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。
3.物理图表
用于描述系统的软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统部署实施过程。
4.处理流程图表
处理流程试图用于描述系统软件组件之间的通信时序，数据的输入输出反应系统的功能流程与数据流程，通常由时序图和流程图表示。
5.开发图表
开发图用于描述系统的模块划分和组成以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
以上就是产品经理应该掌握的技术架构知识，如果你全面了解，就会帮助解决成本估算等问题，更好做出一套高效的产品框架。
今天的分享就在这里。