这是Kevin的第 768 篇原创，

持续日更，做产品经理的创业斜杠青年。

做产品经理，经常会听到一个词叫做：产品框架，基于业务的变化，设计出符合用户生命周期的产品。

可是产品框架式是离不开开发技术基础的，否则产品框架只是一个空纸，比如是当用户量逐渐上升，所提高得服务对性能得要求越来越高，否则用户的体验会越来越差。

最有趣的案例是为什么当初米聊在用户增长后后面在输给了微信的关系，腾讯有QQ先天的高并发优势经验，而作为小米刚起步无论是在经验还是硬件上都没有这样的经验，在高并发状态下，硬件成本可以成指数型增长。

后面在采访中雷军也提到：“这是他们应该赚的钱，我们不擅长”。

▲ 高并发带来的性能与硬件要求

开发语言的知识了解

同时产品研发中，因为市面的业务关系会选择不同的语音作为开发语言，市面上主要是C、PHP、java等为主

1.c语言

主要用于那些对效率要求很高的地方，比如说电脑的各种驱动程序，或者机械制造方面的应用。

2.java语言

桌面应用的j2se，企业应用j2ee，手机应用j2me。桌面应用的话，可以写一些小游戏：贪吃蛇、俄罗斯方块等，后缀名是.jar。企业应用的话，就是说公司里面用的一些管理软件，网站也可以，我记得好像校内网就是用java做的。

3.PHP语言

主要应用于Web开发领域，这两门编程语言在应用场景上几乎没有交叉，所以也相对比较好选择。

当然以上并不是要求产品经理要去从事研发工作，但最好的方式是经验积累，比如是多和后端开发沟通，在多个案例后逐渐不同语言的开发优势

什么是技术架构？

1. 百度解释：

架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策，架构也是产品的结构和愿景。

系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。

做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。

2.架构的种类

架构可以分为逻辑架构、物理架构、系统架构

逻辑架构：

软件系统当中的各个元件之间所存在的关系，比如外部系统接口、用户洁面、商业逻辑元件、数据库等

物理架构：

软件元件分布式系统的物理架构，所有元件都是属于物理设备，住的是有主机、整合服务器、英语服务器、代理服务器、存储服务器、报表服务器web服务器、网络分流器等。

系统架构：

基于各个不同的角度进行分析，都能够了解到划分元件、决定设计这个两个架构的要素

3.架构图

系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。

一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：

1.场景图表

用户描述系统的参与者与功能用例之间的关系没反应系统的最终需求和交互设计

2.逻辑图表

用于描述系统软件功能拆解后的组件关系，组件约束和边界，反应系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。

3.物理图表

用于描述系统的软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于知道软件系统部署实施过程。

4.处理流程图表

处理流程试图用于描述系统软件组件之间的通信时序，数据的输入输出反应系统的功能流程与数据流程，通常由时许图和流程图表示。

5.开发图表

开发图用于描述系统的模块划分和组成以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。

单体应用和微服务

同样的，在早期大部分应用不会考虑到技术架构，但随着用户增加和未来性能要求则需要重构，这就需要到技术资深的架构师。而市面上的架构主要分为下面三类

一个单体应用程序：

就是应用程序的全部功能被一起打包作为单个单元或应用程序.这个单元可以是JAR、WAR、EAR,或其他一些归档格式,但其全部集成在一个单一的单元.

微服务：微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。（百科解释）

单体应用优点：
1.方便调试，代码都在一起；
2.没有分布式开销，所有服务都在本地容器内；
3.中小型项目可以快速迭代，不需要太多资源。

单体应用缺点：
1.可复用性差：服务被打包在应用中，功能不易复用；
2.系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长。
3.线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级。

微服务架构的优点

1.分而治之；单个服务功能内聚，复杂性低；方便团队的拆分和管理；
2.单独部署，独立开发；

微服务架构的缺点

1.开发难度大；垮服务的调用通常是不同的机器，甚至是不同的机房，开发人员需要处理超时、网络异常等问题。
2.效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期。
3.需要分布式事务的支持。

以上就是产品经理应该掌握的技术架构知识，相信后面就会帮助解决成本估算等问题。

参考资料：

https://blog.csdn.net/qq_30347133/article/details/83380025?utm_term=%E5%8D%95%E4%BD%93%E5%BA%94%E7%94%A8%E5%92%8C%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%9A%84%E4%BC%98%E7%BC%BA%E7%82%B9&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~sobaiduweb~default-0-83380025&spm=3001.4430https://zhidao.baidu.com/question/429520780282969652.html?fr=iks&word=C%D3%EF%D1%D4%BA%CDPHP%D3%C5%CA%C6&ie=gbk

我的新书

购买后公众号回复：迭代，进入读者群

点击加入我的社群⬇️⬇️⬇️

推荐阅读：

2020年底福利｜我整理的产品经理PRD、原型资料下载

做了半年短视频，我总结了7条心得

产品经理必了解的技术架构

做产品经理，经常会听到一个词叫做：产品框架，基于业务的变化，设计出符合用户生命周期的产品。