产品经理必须了解的技术架构
做产品经理，在工作中经常有做“产品框架”的需求
它要求了我们要基于业务现在、放眼未来的变化，设计出符合业务生命周期、用户生命周期的产品框架。
可是产品框架式是离不开技术基础的。
微信和米聊
产品的活跃用户量大规模增加后，对应页面加载方式、服务器配置、网络带宽等，都要求越来越高，否则访问速度、系统性能都会降低，从而影响用户体验。
▲▲ 高并发带来的性能与硬件要求
所以，如果离开了技术基础知识，产品框架只是一个空纸。
所以产品经理需要了解一些技术基础知识甚至是技术架构，才能够做出好用的产品框架。
而这里的技术知识我们包含了语言知识、以及技术架构知识。
1.产品经理要了解的技术架构
系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。
软件系统当中的各个元件之间所存在的关系，比如外部系统接口、用户界面、商业逻辑元件、数据库等
软件元件分布式系统的物理架构，所有元件都是属于物理设备，主要有主机、整合服务器、英语服务器、代理服务器、存储服务器、报表服务器web服务器、网络分流器等。
基于各个不同的角度进行分析，都能够了解到划分元件、决定设计这个两个架构的要素
3.架构案例：单体架构和微服务
什么是微服务：
1.方便调试，代码都在一起；
2.没有分布式开销，所有服务都在本地容器内；
3.中小型项目可以快速迭代，不需要太多资源。
1.可复用性差：服务被打包在应用中，功能不易复用；
2.系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长。
3.线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级。
微服务架构的优点
2.单独部署，独立开发；
微服务架构的缺点
2.效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期。
3.需要分布式事务的支持。
2.产品经理去了解的开发语言知识
主要用于那些对效率要求很高的地方，比如说电脑的各种驱动程序，或者机械制造方面的应用。
桌面应用的j2se，企业应用j2ee，手机应用j2me。桌面应用的话，可以写一些小游戏：贪吃蛇、俄罗斯方块等，后缀名是.jar。企业应用的话，就是说公司里面用的一些管理软件，网站也可以，我记得好像校内网就是用java做的。
主要应用于Web开发领域，这两门编程语言在应用场景上几乎没有交叉，所以也相对比较好选择。
以上并不是要求产品经理要去从事研发工作，但最好的方式是经验积累，比如是多和后端开发沟通，在多个案例后逐渐不同语言的开发优势
用户描述系统的参与者与功能用例之间的关系没反应系统的最终需求和交互设计
用于描述系统软件功能拆解后的组件关系，组件约束和边界，反应系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。
用于描述系统的软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统部署实施过程。
处理流程试图用于描述系统软件组件之间的通信时序，数据的输入输出反应系统的功能流程与数据流程，通常由时序图和流程图表示。
5.开发图表
开发图用于描述系统的模块划分和组成以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
以上就是产品经理应该掌握的技术架构知识，如果你全面了解，就会帮助解决成本估算等问题，更好做出一套高效的产品框架。
今天的分享就在这里。
